jiachao2130/cvrf2cusa
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7d8412e76d
cvrf2cusa/cvrf/2024/cvrf-openEuler-SA-2024-1496.xml
Jia Chao 0b34274085 git mv 
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-25 09:57:37 +08:00

1312 lines
56 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1</DocumentTitle>
<DocumentType>Security Advisory</DocumentType>
<DocumentPublisher Type="Vendor">
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
<IssuingAuthority>openEuler security committee</IssuingAuthority>
</DocumentPublisher>
<DocumentTracking>
<Identification>
<ID>openEuler-SA-2024-1496</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-04-26</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-04-26</InitialReleaseDate>
<CurrentReleaseDate>2024-04-26</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-04-26</Date>
</Generator>
</DocumentTracking>
<DocumentNotes>
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1.</Note>
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
vt: fix memory overlapping when deleting chars in the buffer
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.
Fix this problem by using replacing the scr_memcpyw with scr_memmovew.(CVE-2022-48627)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qcom-rng - ensure buffer for generate is completely filled
The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn&apos;t check the return value. This issue can
be reproduced by running the following from libkcapi:
kcapi-rng -b 9000000 &gt; OUTFILE
The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
&apos;val &amp; PRNG_STATUS_DATA_AVAIL&apos; fails.
Let&apos;s fix this issue by ensuring that qcom_rng_read() always returns
with a full buffer if the function returns success. Let&apos;s also have
qcom_rng_generate() return the correct value.
Here&apos;s some statistics from the ent project
(https://www.fourmilab.ch/random/) that shows information about the
quality of the generated numbers:
$ ent -c qcom-random-before
Value Char Occurrences Fraction
0 606748 0.067416
1 33104 0.003678
2 33001 0.003667
...
253 <20> 32883 0.003654
254 <20> 33035 0.003671
255 <20> 33239 0.003693
Total: 9000000 1.000000
Entropy = 7.811590 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 2 percent.
Chi square distribution for 9000000 samples is 9329962.81, and
randomly would exceed this value less than 0.01 percent of the
times.
Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
Serial correlation coefficient is 0.159130 (totally uncorrelated =
0.0).
Without this patch, the results of the chi-square test is 0.01%, and
the numbers are certainly not random according to ent&apos;s project page.
The results improve with this patch:
$ ent -c qcom-random-after
Value Char Occurrences Fraction
0 35432 0.003937
1 35127 0.003903
2 35424 0.003936
...
253 <20> 35201 0.003911
254 <20> 34835 0.003871
255 <20> 35368 0.003930
Total: 9000000 1.000000
Entropy = 7.999979 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 0 percent.
Chi square distribution for 9000000 samples is 258.77, and randomly
would exceed this value 42.24 percent of the times.
Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
Serial correlation coefficient is 0.000468 (totally uncorrelated =
0.0).
This change was tested on a Nexus 5 phone (msm8974 SoC).(CVE-2022-48629)
The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this &quot;could be exploited in a real world scenario.&quot; This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.(CVE-2023-47233)
In the Linux kernel, the following vulnerability has been resolved:
drm: Don&apos;t unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it&apos;s still in use.
Reset fb to NULL once we&apos;ve unreffed it to avoid doing it again
until we&apos;ve done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.(CVE-2023-52486)
In the Linux kernel, the following vulnerability has been resolved:
x86/alternatives: Disable KASAN in apply_alternatives()
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ](CVE-2023-52504)
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.(CVE-2023-52524)
In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
&lt;TASK&gt;
? __die+0x24/0x70
? page_fault_oops+0x82/0x150
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x26/0x30
? vlan_dev_hard_header+0x35/0x140 [8021q]
? vlan_dev_hard_header+0x8e/0x140 [8021q]
neigh_connected_output+0xb2/0x100
ip6_finish_output2+0x1cb/0x520
? nf_hook_slow+0x43/0xc0
? ip6_mtu+0x46/0x80
ip6_finish_output+0x2a/0xb0
mld_sendpack+0x18f/0x250
mld_ifc_work+0x39/0x160
process_one_work+0x1e6/0x3f0
worker_thread+0x4d/0x2f0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c &apos;{&quot;runner&quot;: {&quot;name&quot;: &quot;loadbalance&quot;}}&apos;
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.(CVE-2023-52574)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.(CVE-2023-52607)
A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.(CVE-2023-7042)
A race condition was found in the Linux kernel&apos;s media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
(CVE-2024-24861)
create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi-&gt;leb_size.(CVE-2024-25739)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H &apos;Connection: Close&apos; &lt;URL&gt;
- continuously dump SMC-D connections in parallel:
watch -n 1 &apos;smcss -D&apos;
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
&lt;TASK&gt;
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn-&gt;rmb_desc. So fix it by checking before dump.(CVE-2024-26615)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
The dreamcastcard-&gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&gt;timer.
When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:
(Thread 1) | (Thread 2)
snd_aicapcm_pcm_close() |
... | run_spu_dma() //worker
| mod_timer()
flush_work() |
del_timer() | aica_period_elapsed() //timer
kfree(dreamcastcard-&gt;channel) | schedule_work()
| run_spu_dma() //worker
... | dreamcastcard-&gt;channel-&gt; //USE
In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.(CVE-2024-26654)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
&lt;TASK&gt;
tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().(CVE-2024-26663)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty. Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed. Since this is
broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device.(CVE-2024-26696)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1.
openEuler Security has rated this update as having a security impact of medium. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Medium</Note>
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
</DocumentNotes>
<DocumentReferences>
<Reference Type="Self">
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48627</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48629</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-47233</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52486</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52504</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52524</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52574</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52607</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-7042</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24861</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-25739</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26615</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26654</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26663</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26696</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48627</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48629</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-47233</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52486</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52504</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52524</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52574</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52607</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-7042</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24861</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-25739</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26615</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26654</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26663</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26696</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="kernel-debugsource-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2404.3.0.0247.oe1.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2404.3.0.0247.oe1.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-4.19.90-2404.3.0.0247" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2404.3.0.0247.oe1.x86_64.rpm</FullProductName>
</Branch>
</ProductTree>
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
vt: fix memory overlapping when deleting chars in the buffer
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.
Fix this problem by using replacing the scr_memcpyw with scr_memmovew.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2022-48627</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.4</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
crypto: qcom-rng - ensure buffer for generate is completely filled
The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn&apos;t check the return value. This issue can
be reproduced by running the following from libkcapi:
kcapi-rng -b 9000000 &gt; OUTFILE
The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
&apos;val &amp; PRNG_STATUS_DATA_AVAIL&apos; fails.
Let&apos;s fix this issue by ensuring that qcom_rng_read() always returns
with a full buffer if the function returns success. Let&apos;s also have
qcom_rng_generate() return the correct value.
Here&apos;s some statistics from the ent project
(https://www.fourmilab.ch/random/) that shows information about the
quality of the generated numbers:
$ ent -c qcom-random-before
Value Char Occurrences Fraction
0 606748 0.067416
1 33104 0.003678
2 33001 0.003667
...
253 <20> 32883 0.003654
254 <20> 33035 0.003671
255 <20> 33239 0.003693
Total: 9000000 1.000000
Entropy = 7.811590 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 2 percent.
Chi square distribution for 9000000 samples is 9329962.81, and
randomly would exceed this value less than 0.01 percent of the
times.
Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
Serial correlation coefficient is 0.159130 (totally uncorrelated =
0.0).
Without this patch, the results of the chi-square test is 0.01%, and
the numbers are certainly not random according to ent&apos;s project page.
The results improve with this patch:
$ ent -c qcom-random-after
Value Char Occurrences Fraction
0 35432 0.003937
1 35127 0.003903
2 35424 0.003936
...
253 <20> 35201 0.003911
254 <20> 34835 0.003871
255 <20> 35368 0.003930
Total: 9000000 1.000000
Entropy = 7.999979 bits per byte.
Optimum compression would reduce the size
of this 9000000 byte file by 0 percent.
Chi square distribution for 9000000 samples is 258.77, and randomly
would exceed this value 42.24 percent of the times.
Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
Serial correlation coefficient is 0.000468 (totally uncorrelated =
0.0).
This change was tested on a Nexus 5 phone (msm8974 SoC).</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2022-48629</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this &quot;could be exploited in a real world scenario.&quot; This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-47233</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>6.3</BaseScore>
<Vector>AV:P/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
drm: Don&apos;t unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it&apos;s still in use.
Reset fb to NULL once we&apos;ve unreffed it to avoid doing it again
until we&apos;ve done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-52486</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
x86/alternatives: Disable KASAN in apply_alternatives()
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ]</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-52504</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-52524</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
&lt;TASK&gt;
? __die+0x24/0x70
? page_fault_oops+0x82/0x150
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x26/0x30
? vlan_dev_hard_header+0x35/0x140 [8021q]
? vlan_dev_hard_header+0x8e/0x140 [8021q]
neigh_connected_output+0xb2/0x100
ip6_finish_output2+0x1cb/0x520
? nf_hook_slow+0x43/0xc0
? ip6_mtu+0x46/0x80
ip6_finish_output+0x2a/0xb0
mld_sendpack+0x18f/0x250
mld_ifc_work+0x39/0x160
process_one_work+0x1e6/0x3f0
worker_thread+0x4d/0x2f0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c &apos;{&quot;runner&quot;: {&quot;name&quot;: &quot;loadbalance&quot;}}&apos;
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-52574</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-52607</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="9" xml:lang="en">A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2023-7042</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="10" xml:lang="en">A race condition was found in the Linux kernel&apos;s media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-24861</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>6.3</BaseScore>
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="11" xml:lang="en">create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi-&gt;leb_size.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-25739</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H &apos;Connection: Close&apos; &lt;URL&gt;
- continuously dump SMC-D connections in parallel:
watch -n 1 &apos;smcss -D&apos;
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
&lt;TASK&gt;
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn-&gt;rmb_desc. So fix it by checking before dump.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-26615</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
The dreamcastcard-&gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&gt;timer.
When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:
(Thread 1) | (Thread 2)
snd_aicapcm_pcm_close() |
... | run_spu_dma() //worker
| mod_timer()
flush_work() |
del_timer() | aica_period_elapsed() //timer
kfree(dreamcastcard-&gt;channel) | schedule_work()
| run_spu_dma() //worker
... | dreamcastcard-&gt;channel-&gt; //USE
In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-26654</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
&lt;TASK&gt;
tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-26663</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty. Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed. Since this is
broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device.</Note>
</Notes>
<ReleaseDate>2024-04-26</ReleaseDate>
<CVE>CVE-2024-26696</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-04-26</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1496</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue View Git Blame Copy Permalink