2071 lines
88 KiB
XML
2071 lines
88 KiB
XML
|
<?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-22.03-LTS</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-1498</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-22.03-LTS.</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:
|
|||
|
|
|
|||
|
|
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't check the return value. This issue can
|
|||
|
|
be reproduced by running the following from libkcapi:
|
|||
|
|
|
|||
|
|
kcapi-rng -b 9000000 > OUTFILE
|
|||
|
|
|
|||
|
|
The generated OUTFILE will have three huge sections that contain all
|
|||
|
|
zeros, and this is caused by the code where the test
|
|||
|
|
'val & PRNG_STATUS_DATA_AVAIL' fails.
|
|||
|
|
|
|||
|
|
Let's fix this issue by ensuring that qcom_rng_read() always returns
|
|||
|
|
with a full buffer if the function returns success. Let's also have
|
|||
|
|
qcom_rng_generate() return the correct value.
|
|||
|
|
|
|||
|
|
Here'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'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)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
ksmbd: fix out of bounds in init_smb2_rsp_hdr()
|
|||
|
|
|
|||
|
|
If client send smb2 negotiate request and then send smb1 negotiate
|
|||
|
|
request, init_smb2_rsp_hdr is called for smb1 negotiate request since
|
|||
|
|
need_neg is set to false. This patch ignore smb1 packets after ->need_neg
|
|||
|
|
is set to false.(CVE-2023-52441)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
drm: Don'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's still in use.
|
|||
|
|
|
|||
|
|
Reset fb to NULL once we've unreffed it to avoid doing it again
|
|||
|
|
until we'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:
|
|||
|
|
|
|||
|
|
media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
|
|||
|
|
|
|||
|
|
In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
|
|||
|
|
mtk_jpeg_job_timeout_work.
|
|||
|
|
|
|||
|
|
In mtk_jpeg_dec_device_run, if error happens in
|
|||
|
|
mtk_jpeg_set_dec_dst, it will finally start the worker while
|
|||
|
|
mark the job as finished by invoking v4l2_m2m_job_finish.
|
|||
|
|
|
|||
|
|
There are two methods to trigger the bug. If we remove the
|
|||
|
|
module, it which will call mtk_jpeg_remove to make cleanup.
|
|||
|
|
The possible sequence is as follows, which will cause a
|
|||
|
|
use-after-free bug.
|
|||
|
|
|
|||
|
|
CPU0 CPU1
|
|||
|
|
mtk_jpeg_dec_... |
|
|||
|
|
start worker |
|
|||
|
|
|mtk_jpeg_job_timeout_work
|
|||
|
|
mtk_jpeg_remove |
|
|||
|
|
v4l2_m2m_release |
|
|||
|
|
kfree(m2m_dev); |
|
|||
|
|
|
|
|||
|
|
| v4l2_m2m_get_curr_priv
|
|||
|
|
| m2m_dev->curr_ctx //use
|
|||
|
|
|
|||
|
|
If we close the file descriptor, which will call mtk_jpeg_release,
|
|||
|
|
it will have a similar sequence.
|
|||
|
|
|
|||
|
|
Fix this bug by starting timeout worker only if started jpegdec worker
|
|||
|
|
successfully. Then v4l2_m2m_job_finish will only be called in
|
|||
|
|
either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.(CVE-2023-52491)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
dmaengine: fix NULL pointer in channel unregistration function
|
|||
|
|
|
|||
|
|
__dma_async_device_channel_register() can fail. In case of failure,
|
|||
|
|
chan->local is freed (with free_percpu()), and chan->local is nullified.
|
|||
|
|
When dma_async_device_unregister() is called (because of managed API or
|
|||
|
|
intentionally by DMA controller driver), channels are unconditionally
|
|||
|
|
unregistered, leading to this NULL pointer:
|
|||
|
|
[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
|
|||
|
|
[...]
|
|||
|
|
[ 1.484499] Call trace:
|
|||
|
|
[ 1.486930] device_del+0x40/0x394
|
|||
|
|
[ 1.490314] device_unregister+0x20/0x7c
|
|||
|
|
[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0
|
|||
|
|
|
|||
|
|
Look at dma_async_device_register() function error path, channel device
|
|||
|
|
unregistration is done only if chan->local is not NULL.
|
|||
|
|
|
|||
|
|
Then add the same condition at the beginning of
|
|||
|
|
__dma_async_device_channel_unregister() function, to avoid NULL pointer
|
|||
|
|
issue whatever the API used to reach this function.(CVE-2023-52492)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
bus: mhi: host: Drop chan lock before queuing buffers
|
|||
|
|
|
|||
|
|
Ensure read and write locks for the channel are not taken in succession by
|
|||
|
|
dropping the read lock from parse_xfer_event() such that a callback given
|
|||
|
|
to client can potentially queue buffers and acquire the write lock in that
|
|||
|
|
process. Any queueing of buffers should be done without channel read lock
|
|||
|
|
acquired as it can result in multiple locks and a soft lockup.
|
|||
|
|
|
|||
|
|
[mani: added fixes tag and cc'ed stable](CVE-2023-52493)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
bus: mhi: host: Add alignment check for event ring read pointer
|
|||
|
|
|
|||
|
|
Though we do check the event ring read pointer by "is_valid_ring_ptr"
|
|||
|
|
to make sure it is in the buffer range, but there is another risk the
|
|||
|
|
pointer may be not aligned. Since we are expecting event ring elements
|
|||
|
|
are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
|
|||
|
|
could lead to multiple issues like DoS or ring buffer memory corruption.
|
|||
|
|
|
|||
|
|
So add a alignment check for event ring read pointer.(CVE-2023-52494)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
PM: sleep: Fix possible deadlocks in core system-wide PM code
|
|||
|
|
|
|||
|
|
It is reported that in low-memory situations the system-wide resume core
|
|||
|
|
code deadlocks, because async_schedule_dev() executes its argument
|
|||
|
|
function synchronously if it cannot allocate memory (and not only in
|
|||
|
|
that case) and that function attempts to acquire a mutex that is already
|
|||
|
|
held. Executing the argument function synchronously from within
|
|||
|
|
dpm_async_fn() may also be problematic for ordering reasons (it may
|
|||
|
|
cause a consumer device's resume callback to be invoked before a
|
|||
|
|
requisite supplier device's one, for example).
|
|||
|
|
|
|||
|
|
Address this by changing the code in question to use
|
|||
|
|
async_schedule_dev_nocall() for scheduling the asynchronous
|
|||
|
|
execution of device suspend and resume functions and to directly
|
|||
|
|
run them synchronously if async_schedule_dev_nocall() returns false.(CVE-2023-52498)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
|
|||
|
|
|
|||
|
|
There is a potential race condition in amdtee_close_session that may
|
|||
|
|
cause use-after-free in amdtee_open_session. For instance, if a session
|
|||
|
|
has refcount == 1, and one thread tries to free this session via:
|
|||
|
|
|
|||
|
|
kref_put(&sess->refcount, destroy_session);
|
|||
|
|
|
|||
|
|
the reference count will get decremented, and the next step would be to
|
|||
|
|
call destroy_session(). However, if in another thread,
|
|||
|
|
amdtee_open_session() is called before destroy_session() has completed
|
|||
|
|
execution, alloc_session() may return 'sess' that will be freed up
|
|||
|
|
later in destroy_session() leading to use-after-free in
|
|||
|
|
amdtee_open_session.
|
|||
|
|
|
|||
|
|
To fix this issue, treat decrement of sess->refcount and removal of
|
|||
|
|
'sess' from session list in destroy_session() as a critical section, so
|
|||
|
|
that it is executed atomically.(CVE-2023-52503)
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
<TASK>
|
|||
|
|
? __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 '{"runner": {"name": "loadbalance"}}'
|
|||
|
|
$ 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->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)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
firmware: arm_scmi: Check mailbox/SMT channel for consistency
|
|||
|
|
|
|||
|
|
On reception of a completion interrupt the shared memory area is accessed
|
|||
|
|
to retrieve the message header at first and then, if the message sequence
|
|||
|
|
number identifies a transaction which is still pending, the related
|
|||
|
|
payload is fetched too.
|
|||
|
|
|
|||
|
|
When an SCMI command times out the channel ownership remains with the
|
|||
|
|
platform until eventually a late reply is received and, as a consequence,
|
|||
|
|
any further transmission attempt remains pending, waiting for the channel
|
|||
|
|
to be relinquished by the platform.
|
|||
|
|
|
|||
|
|
Once that late reply is received the channel ownership is given back
|
|||
|
|
to the agent and any pending request is then allowed to proceed and
|
|||
|
|
overwrite the SMT area of the just delivered late reply; then the wait
|
|||
|
|
for the reply to the new request starts.
|
|||
|
|
|
|||
|
|
It has been observed that the spurious IRQ related to the late reply can
|
|||
|
|
be wrongly associated with the freshly enqueued request: when that happens
|
|||
|
|
the SCMI stack in-flight lookup procedure is fooled by the fact that the
|
|||
|
|
message header now present in the SMT area is related to the new pending
|
|||
|
|
transaction, even though the real reply has still to arrive.
|
|||
|
|
|
|||
|
|
This race-condition on the A2P channel can be detected by looking at the
|
|||
|
|
channel status bits: a genuine reply from the platform will have set the
|
|||
|
|
channel free bit before triggering the completion IRQ.
|
|||
|
|
|
|||
|
|
Add a consistency check to validate such condition in the A2P ISR.(CVE-2023-52608)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
PCI: switchtec: Fix stdev_release() crash after surprise hot remove
|
|||
|
|
|
|||
|
|
A PCI device hot removal may occur while stdev->cdev is held open. The call
|
|||
|
|
to stdev_release() then happens during close or exit, at a point way past
|
|||
|
|
switchtec_pci_remove(). Otherwise the last ref would vanish with the
|
|||
|
|
trailing put_device(), just before return.
|
|||
|
|
|
|||
|
|
At that later point in time, the devm cleanup has already removed the
|
|||
|
|
stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
|
|||
|
|
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
|
|||
|
|
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
|
|||
|
|
would pass a stale &stdev->pdev->dev pointer.
|
|||
|
|
|
|||
|
|
Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
|
|||
|
|
stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
|
|||
|
|
future accidents.
|
|||
|
|
|
|||
|
|
Reproducible via the script at
|
|||
|
|
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com(CVE-2023-52617)
|
|||
|
|
|
|||
|
|
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'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)
|
|||
|
|
|
|||
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
ksmbd: fix global oob in ksmbd_nl_policy
|
|||
|
|
|
|||
|
|
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
|
|||
|
|
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
|
|||
|
|
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
|
|||
|
|
trace below:
|
|||
|
|
|
|||
|
|
==================================================================
|
|||
|
|
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
|
|||
|
|
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|||
|
|
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
|
|||
|
|
|
|||
|
|
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3
|
|||
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|||
|
|
Call Trace:
|
|||
|
|
<TASK>
|
|||
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|||
|
|
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
|
|||
|
|
print_address_description mm/kasan/report.c:284 [inline]
|
|||
|
|
print_report+0x172/0x475 mm/kasan/report.c:395
|
|||
|
|
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
|
|||
|
|
validate_nla lib/nlattr.c:386 [inline]
|
|||
|
|
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|||
|
|
__nla_parse+0x3e/0x50 lib/nlattr.c:697
|
|||
|
|
__nlmsg_parse include/net/netlink.h:748 [inline]
|
|||
|
|
genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
|
|||
|
|
genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
|
|||
|
|
genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
|
|||
|
|
genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
|
|||
|
|
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
|
|||
|
|
genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
|
|||
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|||
|
|
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
|
|||
|
|
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
|
|||
|
|
sock_sendmsg_nosec net/socket.c:714 [inline]
|
|||
|
|
sock_sendmsg+0x154/0x190 net/socket.c:734
|
|||
|
|
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
|
|||
|
|
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
|
|||
|
|
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
|
|||
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|||
|
|
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
|
|||
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|||
|
|
RIP: 0033:0x7fdd66a8f359
|
|||
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|||
|
|
RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|||
|
|
RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
|
|||
|
|
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
|
|||
|
|
RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
|
|||
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|||
|
|
R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
|
|||
|
|
</TASK>
|
|||
|
|
|
|||
|
|
The buggy address belongs to the variable:
|
|||
|
|
ksmbd_nl_policy+0x100/0xa80
|
|||
|
|
|
|||
|
|
The buggy address belongs to the physical page:
|
|||
|
|
page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
|
|||
|
|
flags: 0x200000000001000(reserved|node=0|zone=2)
|
|||
|
|
raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
|
|||
|
|
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
|
|||
|
|
page dumped because: kasan: bad access detected
|
|||
|
|
|
|||
|
|
Memory state around the buggy address:
|
|||
|
|
ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|||
|
|
ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|||
|
|
>ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
|
|||
|
|
^
|
|||
|
|
ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
|
|||
|
|
ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
|
|||
|
|
==================================================================
|
|||
|
|
|
|||
|
|
To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
|
|||
|
|
KSMBD_EVENT_MAX to be its original value - 1 according to what other
|
|||
|
|
netlink families do. Also change two sites that refer the
|
|||
|
|
KSMBD_EVENT_MAX to correct value.(CVE-2024-26608)
|
|||
|
|
|
|||
|
|
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 <duration> -H 'Connection: Close' <URL>
|
|||
|
|
|
|||
|
|
- continuously dump SMC-D connections in parallel:
|
|||
|
|
watch -n 1 'smcss -D'
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
<TASK>
|
|||
|
|
? __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->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->timer could schedule the spu_dma_work and the
|
|||
|
|
spu_dma_work could also arm the dreamcastcard->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->channel) | schedule_work()
|
|||
|
|
| run_spu_dma() //worker
|
|||
|
|
... | dreamcastcard->channel-> //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:
|
|||
|
|
|
|||
|
|
drm/amdgpu: fix use-after-free bug
|
|||
|
|
|
|||
|
|
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
|
|||
|
|
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
|
|||
|
|
The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>.
|
|||
|
|
For example the following code:
|
|||
|
|
|
|||
|
|
static void Syzkaller1(int fd)
|
|||
|
|
{
|
|||
|
|
struct drm_amdgpu_gem_userptr arg;
|
|||
|
|
int ret;
|
|||
|
|
|
|||
|
|
arg.addr = 0xffffffffffff0000;
|
|||
|
|
arg.size = 0x80000000; /*2 Gb*/
|
|||
|
|
arg.flags = 0x7;
|
|||
|
|
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
Due to the address and size are not valid there is a failure in
|
|||
|
|
amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->
|
|||
|
|
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
|
|||
|
|
amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.
|
|||
|
|
The following stack is below when the issue is reproduced when Kazan is enabled:
|
|||
|
|
|
|||
|
|
[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
|
|||
|
|
[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
|
|||
|
|
[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
|
|||
|
|
[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
|
|||
|
|
[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
|
|||
|
|
[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
|
|||
|
|
[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
|
|||
|
|
[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
|
|||
|
|
[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
|
|||
|
|
[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|||
|
|
[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
|
|||
|
|
[ +0.000010] Call Trace:
|
|||
|
|
[ +0.000006] <TASK>
|
|||
|
|
[ +0.000007] ? show_regs+0x6a/0x80
|
|||
|
|
[ +0.000018] ? __warn+0xa5/0x1b0
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000018] ? report_bug+0x24a/0x290
|
|||
|
|
[ +0.000022] ? handle_bug+0x46/0x90
|
|||
|
|
[ +0.000015] ? exc_invalid_op+0x19/0x50
|
|||
|
|
[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20
|
|||
|
|
[ +0.000017] ? kasan_save_stack+0x26/0x50
|
|||
|
|
[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340
|
|||
|
|
[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10
|
|||
|
|
[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30
|
|||
|
|
[ +0.000018] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0
|
|||
|
|
[ +0.000018] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000013] ? __kasan_check_read+0x11/0x20
|
|||
|
|
[ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
|
|||
|
|
[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
|
|||
|
|
[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004291] ? do_syscall_64+0x5f/0xe0
|
|||
|
|
[ +0.000023] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]
|
|||
|
|
[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
|
|||
|
|
[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004270] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20
|
|||
|
|
[ +0.000015] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0
|
|||
|
|
[ +0.000020] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
|
|||
|
|
[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
|
|||
|
|
[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]
|
|||
|
|
[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]
|
|||
|
|
[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d
|
|||
|
|
---truncated---(CVE-2024-26656)
|
|||
|
|
|
|||
|
|
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-22.03-LTS.
|
|||
|
|
|
|||
|
|
openEuler Security has rated this update as having a security impact of high. 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">High</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-1498</URL>
|
|||
|
|
</Reference>
|
|||
|
|
<Reference Type="openEuler CVE">
|
|||
|
|
<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-52441</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-52491</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52492</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52493</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52494</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52498</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52503</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-52608</URL>
|
|||
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52617</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-26608</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-26656</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-48629</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52441</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52486</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52491</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52492</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52493</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52494</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52498</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52503</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-52608</URL>
|
|||
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52617</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-26608</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-26656</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-22.03-LTS" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
|
|||
|
|
</Branch>
|
|||
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|||
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="bpftool-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="perf-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.135.0.162.oe2203.aarch64.rpm</FullProductName>
|
|||
|
|
</Branch>
|
|||
|
|
<Branch Type="Package Arch" Name="src">
|
|||
|
|
<FullProductName ProductID="kernel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.135.0.162.oe2203.src.rpm</FullProductName>
|
|||
|
|
</Branch>
|
|||
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|||
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="perf-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.135.0.162.oe2203.x86_64.rpm</FullProductName>
|
|||
|
|
<FullProductName ProductID="bpftool-5.10.0-60.135.0.162" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.135.0.162.oe2203.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:
|
|||
|
|
|
|||
|
|
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't check the return value. This issue can
|
|||
|
|
be reproduced by running the following from libkcapi:
|
|||
|
|
|
|||
|
|
kcapi-rng -b 9000000 > OUTFILE
|
|||
|
|
|
|||
|
|
The generated OUTFILE will have three huge sections that contain all
|
|||
|
|
zeros, and this is caused by the code where the test
|
|||
|
|
'val & PRNG_STATUS_DATA_AVAIL' fails.
|
|||
|
|
|
|||
|
|
Let's fix this issue by ensuring that qcom_rng_read() always returns
|
|||
|
|
with a full buffer if the function returns success. Let's also have
|
|||
|
|
qcom_rng_generate() return the correct value.
|
|||
|
|
|
|||
|
|
Here'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'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-22.03-LTS</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-1498</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:ksmbd: fix out of bounds in init_smb2_rsp_hdr()If client send smb2 negotiate request and then send smb1 negotiaterequest, init_smb2_rsp_hdr is called for smb1 negotiate request sinceneed_neg is set to false. This patch ignore smb1 packets after ->need_negis set to false.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52441</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>High</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>7.8</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/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-1498</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">In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
drm: Don'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's still in use.
|
|||
|
|
|
|||
|
|
Reset fb to NULL once we've unreffed it to avoid doing it again
|
|||
|
|
until we'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-22.03-LTS</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-1498</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:
|
|||
|
|
|
|||
|
|
media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
|
|||
|
|
|
|||
|
|
In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
|
|||
|
|
mtk_jpeg_job_timeout_work.
|
|||
|
|
|
|||
|
|
In mtk_jpeg_dec_device_run, if error happens in
|
|||
|
|
mtk_jpeg_set_dec_dst, it will finally start the worker while
|
|||
|
|
mark the job as finished by invoking v4l2_m2m_job_finish.
|
|||
|
|
|
|||
|
|
There are two methods to trigger the bug. If we remove the
|
|||
|
|
module, it which will call mtk_jpeg_remove to make cleanup.
|
|||
|
|
The possible sequence is as follows, which will cause a
|
|||
|
|
use-after-free bug.
|
|||
|
|
|
|||
|
|
CPU0 CPU1
|
|||
|
|
mtk_jpeg_dec_... |
|
|||
|
|
start worker |
|
|||
|
|
|mtk_jpeg_job_timeout_work
|
|||
|
|
mtk_jpeg_remove |
|
|||
|
|
v4l2_m2m_release |
|
|||
|
|
kfree(m2m_dev); |
|
|||
|
|
|
|
|||
|
|
| v4l2_m2m_get_curr_priv
|
|||
|
|
| m2m_dev->curr_ctx //use
|
|||
|
|
|
|||
|
|
If we close the file descriptor, which will call mtk_jpeg_release,
|
|||
|
|
it will have a similar sequence.
|
|||
|
|
|
|||
|
|
Fix this bug by starting timeout worker only if started jpegdec worker
|
|||
|
|
successfully. Then v4l2_m2m_job_finish will only be called in
|
|||
|
|
either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52491</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>6.2</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:L/PR:N/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-1498</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:
|
|||
|
|
|
|||
|
|
dmaengine: fix NULL pointer in channel unregistration function
|
|||
|
|
|
|||
|
|
__dma_async_device_channel_register() can fail. In case of failure,
|
|||
|
|
chan->local is freed (with free_percpu()), and chan->local is nullified.
|
|||
|
|
When dma_async_device_unregister() is called (because of managed API or
|
|||
|
|
intentionally by DMA controller driver), channels are unconditionally
|
|||
|
|
unregistered, leading to this NULL pointer:
|
|||
|
|
[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
|
|||
|
|
[...]
|
|||
|
|
[ 1.484499] Call trace:
|
|||
|
|
[ 1.486930] device_del+0x40/0x394
|
|||
|
|
[ 1.490314] device_unregister+0x20/0x7c
|
|||
|
|
[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0
|
|||
|
|
|
|||
|
|
Look at dma_async_device_register() function error path, channel device
|
|||
|
|
unregistration is done only if chan->local is not NULL.
|
|||
|
|
|
|||
|
|
Then add the same condition at the beginning of
|
|||
|
|
__dma_async_device_channel_unregister() function, to avoid NULL pointer
|
|||
|
|
issue whatever the API used to reach this function.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52492</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>6.2</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:L/PR:N/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-1498</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:
|
|||
|
|
|
|||
|
|
bus: mhi: host: Drop chan lock before queuing buffers
|
|||
|
|
|
|||
|
|
Ensure read and write locks for the channel are not taken in succession by
|
|||
|
|
dropping the read lock from parse_xfer_event() such that a callback given
|
|||
|
|
to client can potentially queue buffers and acquire the write lock in that
|
|||
|
|
process. Any queueing of buffers should be done without channel read lock
|
|||
|
|
acquired as it can result in multiple locks and a soft lockup.
|
|||
|
|
|
|||
|
|
[mani: added fixes tag and cc'ed stable]</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52493</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>5.1</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:H/PR:N/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-1498</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:
|
|||
|
|
|
|||
|
|
bus: mhi: host: Add alignment check for event ring read pointer
|
|||
|
|
|
|||
|
|
Though we do check the event ring read pointer by "is_valid_ring_ptr"
|
|||
|
|
to make sure it is in the buffer range, but there is another risk the
|
|||
|
|
pointer may be not aligned. Since we are expecting event ring elements
|
|||
|
|
are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
|
|||
|
|
could lead to multiple issues like DoS or ring buffer memory corruption.
|
|||
|
|
|
|||
|
|
So add a alignment check for event ring read pointer.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52494</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>4.4</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:L/PR:H/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-1498</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:
|
|||
|
|
|
|||
|
|
PM: sleep: Fix possible deadlocks in core system-wide PM code
|
|||
|
|
|
|||
|
|
It is reported that in low-memory situations the system-wide resume core
|
|||
|
|
code deadlocks, because async_schedule_dev() executes its argument
|
|||
|
|
function synchronously if it cannot allocate memory (and not only in
|
|||
|
|
that case) and that function attempts to acquire a mutex that is already
|
|||
|
|
held. Executing the argument function synchronously from within
|
|||
|
|
dpm_async_fn() may also be problematic for ordering reasons (it may
|
|||
|
|
cause a consumer device's resume callback to be invoked before a
|
|||
|
|
requisite supplier device's one, for example).
|
|||
|
|
|
|||
|
|
Address this by changing the code in question to use
|
|||
|
|
async_schedule_dev_nocall() for scheduling the asynchronous
|
|||
|
|
execution of device suspend and resume functions and to directly
|
|||
|
|
run them synchronously if async_schedule_dev_nocall() returns false.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52498</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>4.4</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:L/PR:H/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-1498</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">In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
|
|||
|
|
|
|||
|
|
There is a potential race condition in amdtee_close_session that may
|
|||
|
|
cause use-after-free in amdtee_open_session. For instance, if a session
|
|||
|
|
has refcount == 1, and one thread tries to free this session via:
|
|||
|
|
|
|||
|
|
kref_put(&sess->refcount, destroy_session);
|
|||
|
|
|
|||
|
|
the reference count will get decremented, and the next step would be to
|
|||
|
|
call destroy_session(). However, if in another thread,
|
|||
|
|
amdtee_open_session() is called before destroy_session() has completed
|
|||
|
|
execution, alloc_session() may return 'sess' that will be freed up
|
|||
|
|
later in destroy_session() leading to use-after-free in
|
|||
|
|
amdtee_open_session.
|
|||
|
|
|
|||
|
|
To fix this issue, treat decrement of sess->refcount and removal of
|
|||
|
|
'sess' from session list in destroy_session() as a critical section, so
|
|||
|
|
that it is executed atomically.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52503</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>4.5</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:L/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-1498</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">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-22.03-LTS</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-1498</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">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-22.03-LTS</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-1498</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:
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
<TASK>
|
|||
|
|
? __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 '{"runner": {"name": "loadbalance"}}'
|
|||
|
|
$ 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->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-22.03-LTS</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-1498</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:
|
|||
|
|
|
|||
|
|
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-22.03-LTS</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-1498</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:
|
|||
|
|
|
|||
|
|
firmware: arm_scmi: Check mailbox/SMT channel for consistency
|
|||
|
|
|
|||
|
|
On reception of a completion interrupt the shared memory area is accessed
|
|||
|
|
to retrieve the message header at first and then, if the message sequence
|
|||
|
|
number identifies a transaction which is still pending, the related
|
|||
|
|
payload is fetched too.
|
|||
|
|
|
|||
|
|
When an SCMI command times out the channel ownership remains with the
|
|||
|
|
platform until eventually a late reply is received and, as a consequence,
|
|||
|
|
any further transmission attempt remains pending, waiting for the channel
|
|||
|
|
to be relinquished by the platform.
|
|||
|
|
|
|||
|
|
Once that late reply is received the channel ownership is given back
|
|||
|
|
to the agent and any pending request is then allowed to proceed and
|
|||
|
|
overwrite the SMT area of the just delivered late reply; then the wait
|
|||
|
|
for the reply to the new request starts.
|
|||
|
|
|
|||
|
|
It has been observed that the spurious IRQ related to the late reply can
|
|||
|
|
be wrongly associated with the freshly enqueued request: when that happens
|
|||
|
|
the SCMI stack in-flight lookup procedure is fooled by the fact that the
|
|||
|
|
message header now present in the SMT area is related to the new pending
|
|||
|
|
transaction, even though the real reply has still to arrive.
|
|||
|
|
|
|||
|
|
This race-condition on the A2P channel can be detected by looking at the
|
|||
|
|
channel status bits: a genuine reply from the platform will have set the
|
|||
|
|
channel free bit before triggering the completion IRQ.
|
|||
|
|
|
|||
|
|
Add a consistency check to validate such condition in the A2P ISR.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52608</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</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-1498</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:
|
|||
|
|
|
|||
|
|
PCI: switchtec: Fix stdev_release() crash after surprise hot remove
|
|||
|
|
|
|||
|
|
A PCI device hot removal may occur while stdev->cdev is held open. The call
|
|||
|
|
to stdev_release() then happens during close or exit, at a point way past
|
|||
|
|
switchtec_pci_remove(). Otherwise the last ref would vanish with the
|
|||
|
|
trailing put_device(), just before return.
|
|||
|
|
|
|||
|
|
At that later point in time, the devm cleanup has already removed the
|
|||
|
|
stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
|
|||
|
|
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
|
|||
|
|
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
|
|||
|
|
would pass a stale &stdev->pdev->dev pointer.
|
|||
|
|
|
|||
|
|
Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
|
|||
|
|
stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
|
|||
|
|
future accidents.
|
|||
|
|
|
|||
|
|
Reproducible via the script at
|
|||
|
|
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2023-52617</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>4.4</BaseScore>
|
|||
|
|
<Vector>AV:L/AC:L/PR:H/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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" 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-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">A race condition was found in the Linux kernel'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-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
ksmbd: fix global oob in ksmbd_nl_policy
|
|||
|
|
|
|||
|
|
Similar to a reported issue (check the commit b33fb5b801c6 ("net:
|
|||
|
|
qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
|
|||
|
|
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
|
|||
|
|
trace below:
|
|||
|
|
|
|||
|
|
==================================================================
|
|||
|
|
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
|
|||
|
|
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|||
|
|
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
|
|||
|
|
|
|||
|
|
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3
|
|||
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|||
|
|
Call Trace:
|
|||
|
|
<TASK>
|
|||
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|||
|
|
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
|
|||
|
|
print_address_description mm/kasan/report.c:284 [inline]
|
|||
|
|
print_report+0x172/0x475 mm/kasan/report.c:395
|
|||
|
|
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
|
|||
|
|
validate_nla lib/nlattr.c:386 [inline]
|
|||
|
|
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|||
|
|
__nla_parse+0x3e/0x50 lib/nlattr.c:697
|
|||
|
|
__nlmsg_parse include/net/netlink.h:748 [inline]
|
|||
|
|
genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
|
|||
|
|
genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
|
|||
|
|
genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
|
|||
|
|
genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
|
|||
|
|
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
|
|||
|
|
genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
|
|||
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|||
|
|
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
|
|||
|
|
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
|
|||
|
|
sock_sendmsg_nosec net/socket.c:714 [inline]
|
|||
|
|
sock_sendmsg+0x154/0x190 net/socket.c:734
|
|||
|
|
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
|
|||
|
|
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
|
|||
|
|
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
|
|||
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|||
|
|
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
|
|||
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|||
|
|
RIP: 0033:0x7fdd66a8f359
|
|||
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|||
|
|
RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|||
|
|
RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
|
|||
|
|
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
|
|||
|
|
RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
|
|||
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|||
|
|
R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
|
|||
|
|
</TASK>
|
|||
|
|
|
|||
|
|
The buggy address belongs to the variable:
|
|||
|
|
ksmbd_nl_policy+0x100/0xa80
|
|||
|
|
|
|||
|
|
The buggy address belongs to the physical page:
|
|||
|
|
page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
|
|||
|
|
flags: 0x200000000001000(reserved|node=0|zone=2)
|
|||
|
|
raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
|
|||
|
|
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
|
|||
|
|
page dumped because: kasan: bad access detected
|
|||
|
|
|
|||
|
|
Memory state around the buggy address:
|
|||
|
|
ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|||
|
|
ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|||
|
|
>ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
|
|||
|
|
^
|
|||
|
|
ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
|
|||
|
|
ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
|
|||
|
|
==================================================================
|
|||
|
|
|
|||
|
|
To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
|
|||
|
|
KSMBD_EVENT_MAX to be its original value - 1 according to what other
|
|||
|
|
netlink families do. Also change two sites that refer the
|
|||
|
|
KSMBD_EVENT_MAX to correct value.</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2024-26608</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|||
|
|
</Status>
|
|||
|
|
</ProductStatuses>
|
|||
|
|
<Threats>
|
|||
|
|
<Threat Type="Impact">
|
|||
|
|
<Description>Medium</Description>
|
|||
|
|
</Threat>
|
|||
|
|
</Threats>
|
|||
|
|
<CVSSScoreSets>
|
|||
|
|
<ScoreSet>
|
|||
|
|
<BaseScore>6.5</BaseScore>
|
|||
|
|
<Vector>AV:N/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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="19" 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 <duration> -H 'Connection: Close' <URL>
|
|||
|
|
|
|||
|
|
- continuously dump SMC-D connections in parallel:
|
|||
|
|
watch -n 1 'smcss -D'
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
<TASK>
|
|||
|
|
? __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->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-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" 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->timer could schedule the spu_dma_work and the
|
|||
|
|
spu_dma_work could also arm the dreamcastcard->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->channel) | schedule_work()
|
|||
|
|
| run_spu_dma() //worker
|
|||
|
|
... | dreamcastcard->channel-> //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-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|||
|
|
|
|||
|
|
drm/amdgpu: fix use-after-free bug
|
|||
|
|
|
|||
|
|
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
|
|||
|
|
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
|
|||
|
|
The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>.
|
|||
|
|
For example the following code:
|
|||
|
|
|
|||
|
|
static void Syzkaller1(int fd)
|
|||
|
|
{
|
|||
|
|
struct drm_amdgpu_gem_userptr arg;
|
|||
|
|
int ret;
|
|||
|
|
|
|||
|
|
arg.addr = 0xffffffffffff0000;
|
|||
|
|
arg.size = 0x80000000; /*2 Gb*/
|
|||
|
|
arg.flags = 0x7;
|
|||
|
|
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
Due to the address and size are not valid there is a failure in
|
|||
|
|
amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->
|
|||
|
|
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
|
|||
|
|
amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.
|
|||
|
|
The following stack is below when the issue is reproduced when Kazan is enabled:
|
|||
|
|
|
|||
|
|
[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
|
|||
|
|
[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
|
|||
|
|
[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
|
|||
|
|
[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
|
|||
|
|
[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
|
|||
|
|
[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
|
|||
|
|
[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
|
|||
|
|
[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
|
|||
|
|
[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
|
|||
|
|
[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|||
|
|
[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
|
|||
|
|
[ +0.000010] Call Trace:
|
|||
|
|
[ +0.000006] <TASK>
|
|||
|
|
[ +0.000007] ? show_regs+0x6a/0x80
|
|||
|
|
[ +0.000018] ? __warn+0xa5/0x1b0
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000018] ? report_bug+0x24a/0x290
|
|||
|
|
[ +0.000022] ? handle_bug+0x46/0x90
|
|||
|
|
[ +0.000015] ? exc_invalid_op+0x19/0x50
|
|||
|
|
[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20
|
|||
|
|
[ +0.000017] ? kasan_save_stack+0x26/0x50
|
|||
|
|
[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
|
|||
|
|
[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340
|
|||
|
|
[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10
|
|||
|
|
[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30
|
|||
|
|
[ +0.000018] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0
|
|||
|
|
[ +0.000018] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000013] ? __kasan_check_read+0x11/0x20
|
|||
|
|
[ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
|
|||
|
|
[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
|
|||
|
|
[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004291] ? do_syscall_64+0x5f/0xe0
|
|||
|
|
[ +0.000023] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]
|
|||
|
|
[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
|
|||
|
|
[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004270] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20
|
|||
|
|
[ +0.000015] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0
|
|||
|
|
[ +0.000020] ? srso_return_thunk+0x5/0x5f
|
|||
|
|
[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
|
|||
|
|
[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
|
|||
|
|
[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]
|
|||
|
|
[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]
|
|||
|
|
[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
|
|||
|
|
[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d
|
|||
|
|
---truncated---</Note>
|
|||
|
|
</Notes>
|
|||
|
|
<ReleaseDate>2024-04-26</ReleaseDate>
|
|||
|
|
<CVE>CVE-2024-26656</CVE>
|
|||
|
|
<ProductStatuses>
|
|||
|
|
<Status Type="Fixed">
|
|||
|
|
<ProductID>openEuler-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|||
|
|
<Notes>
|
|||
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" 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-22.03-LTS</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-1498</URL>
|
|||
|
|
</Remediation>
|
|||
|
|
</Remediations>
|
|||
|
|
</Vulnerability>
|
|||
|
|
</cvrfdoc>
|