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

1434 lines
64 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</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-1765</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-06-28</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-06-28</InitialReleaseDate>
<CurrentReleaseDate>2024-06-28</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-06-28</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-SP3.</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:
spi: Fix deadlock when adding SPI controllers on SPI buses
Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we&apos;re not trying to reuse a chip
select that&apos;s already controlled. This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock. Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.(CVE-2021-47469)
(CVE-2023-39180)
In the Linux kernel, the following vulnerability has been resolved:
hid: cp2112: Fix duplicate workqueue initialization
Previously the cp2112 driver called INIT_DELAYED_WORK within
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
workqueue on subsequent IRQ startups following an initial request. This
resulted in a warning in set_work_data in workqueue.c, as well as a rare
NULL dereference within process_one_work in workqueue.c.
Initialize the workqueue within _probe instead.(CVE-2023-52853)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
The race is between the handling of a new TCP connection and
its disconnection. It leads to UAF on `struct tcp_transport` in
ksmbd_tcp_new_connection() function.(CVE-2024-26592)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section
between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
worker could collect expired objects and get the released commit lock
within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load
module dependencies, then it goes back to replay the transaction again.
Move it at the end of the abort phase after nft_gc_seq_end() is called.(CVE-2024-26925)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:
=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x48
dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
wilc_parse_join_bss_param from connect+0x2c4/0x648
connect from cfg80211_connect+0x30c/0xb74
cfg80211_connect from nl80211_connect+0x860/0xa94
nl80211_connect from genl_rcv_msg+0x3fc/0x59c
genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
netlink_rcv_skb from genl_rcv+0x2c/0x3c
genl_rcv from netlink_unicast+0x3b0/0x550
netlink_unicast from netlink_sendmsg+0x368/0x688
netlink_sendmsg from ____sys_sendmsg+0x190/0x430
____sys_sendmsg from ___sys_sendmsg+0x110/0x158
___sys_sendmsg from sys_sendmsg+0xe8/0x150
sys_sendmsg from ret_fast_syscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data(CVE-2024-27053)
In the Linux kernel, the following vulnerability has been resolved:
media: tc358743: register v4l2 async device only after successful setup
Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.(CVE-2024-35830)
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix possible cp null dereference
cp might be null, calling cp-&gt;cp_conn would produce null dereference
[Simon Horman adds:]
Analysis:
* cp is a parameter of __rds_rdma_map and is not reassigned.
* The following call-sites pass a NULL cp argument to __rds_rdma_map()
- rds_get_mr()
- rds_get_mr_for_dest
* Prior to the code above, the following assumes that cp may be NULL
(which is indicative, but could itself be unnecessary)
trans_private = rs-&gt;rs_transport-&gt;get_mr(
sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,
args-&gt;vec.addr, args-&gt;vec.bytes,
need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
* The code modified by this patch is guarded by IS_ERR(trans_private),
where trans_private is assigned as per the previous point in this analysis.
The only implementation of get_mr that I could locate is rds_ib_get_mr()
which can return an ERR_PTR if the conn (4th) argument is NULL.
* ret is set to PTR_ERR(trans_private).
rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
Thus ret may be -ENODEV in which case the code in question will execute.
Conclusion:
* cp may be NULL at the point where this patch adds a check;
this patch does seem to address a possible bug(CVE-2024-35902)
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULE_STATE_LIVE -&gt;
MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will take
a time. `is_module_text_address()` and `__module_text_address()`
works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
If we use `is_module_text_address()` and `__module_text_address()`
separately, there is a chance that the first one is succeeded but the
next one is failed because module-&gt;state becomes MODULE_STATE_UNFORMED
between those operations.
In `check_kprobe_address_safe()`, if the second `__module_text_address()`
is failed, that is ignored because it expected a kernel_text address.
But it may have failed simply because module-&gt;state has been changed
to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
non-exist module text address (use-after-free).
To fix this problem, we should not use separated `is_module_text_address()`
and `__module_text_address()`, but use only `__module_text_address()`
once and do `try_module_get(module)` which is only available with
MODULE_STATE_LIVE.(CVE-2024-35955)
In the Linux kernel, the following vulnerability has been resolved:
firewire: ohci: mask bus reset interrupts between ISR and bottom half
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.
Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.
irq_handler logs the bus reset interrupt. However, we can&apos;t clear the bus
reset event flag in irq_handler, because we won&apos;t service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with &quot;modprobe firewire_ohci debug=-1&quot; (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.
This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.
irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won&apos;t be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.(CVE-2024-36950)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix division by zero in setup_dsc_config
When slice_height is 0, the division by slice_height in the calculation
of the number of slices will cause a division by zero driver crash. This
leaves the kernel in a state that requires a reboot. This patch adds a
check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
connected via Thunderbolt. The amdgpu driver crashed with this exception
when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor
is connected and the system is rebooted. I believe this is the same
issue reported for 3113.(CVE-2024-36969)
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
q-&gt;bands will be assigned to qopt-&gt;bands to execute subsequent code logic
after kmalloc. So the old q-&gt;bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount.(CVE-2024-38545)
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() { | delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE! | ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
xa_erase_irq() to avoid deadlock.(CVE-2024-38591)
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
value changed: 0x01 -&gt; 0x03
The line numbers are related to commit dd5a440a31fa (&quot;Linux 6.9-rc7&quot;).
Commit e1d09c2c2f57 (&quot;af_unix: Fix data races around sk-&gt;sk_shutdown.&quot;)
addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the
new page. Following that, if the operation is successful,
old-&gt;list.next-&gt;prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or
page-&gt;next-&gt;prev might not be equal back to page for some page in the
ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:
[ 190.271762] ------------[ cut here ]------------
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[ 190.271789] Modules linked in: [...]
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[ 190.272023] Code: [...]
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 190.272077] Call Trace:
[ 190.272098] &lt;TASK&gt;
[ 190.272189] ring_buffer_resize+0x2ab/0x460
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
[ 190.272216] tracing_entries_write+0x74/0xc0
[ 190.272225] vfs_write+0xf5/0x420
[ 190.272248] ksys_write+0x67/0xe0
[ 190.272256] do_syscall_64+0x82/0x170
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 190.272373] RIP: 0033:0x7f1bd657d263
[ 190.272381] Code: [...]
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
[ 190.272412] &lt;/TASK&gt;
[ 190.272414] ---[ end trace 0000000000000000 ]---
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
trace_buffer has recording disabled. Recent commit d78ab792705c
(&quot;tracing: Stop current tracer when resizing buffer&quot;) causes that it is
now always the case which makes it more likely to experience this issue.
The window to hit this race is nonetheless very small. To help
reproducing it, one can add a delay loop in rb_get_reader_page():
ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);
if (!ret)
goto spin;
for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++) /* inserted delay loop */
__asm__ __volatile__ (&quot;&quot; : : : &quot;memory&quot;);
rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;
..
---truncated---(CVE-2024-38601)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
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-1765</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47469</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-39180</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52853</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26592</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26925</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27053</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35830</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35902</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35955</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36950</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36969</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36978</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38545</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38588</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38591</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38596</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38601</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47469</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-39180</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52853</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26592</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26925</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27053</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35830</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35902</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35955</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36950</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36969</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36978</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38545</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38588</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38591</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38596</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38601</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-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="perf-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-215.0.0.119.oe2203sp3.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-215.0.0.119.oe2203sp3.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="kernel-devel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-215.0.0.119.oe2203sp3.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-215.0.0.119" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-215.0.0.119.oe2203sp3.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:
spi: Fix deadlock when adding SPI controllers on SPI buses
Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we&apos;re not trying to reuse a chip
select that&apos;s already controlled. This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock. Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2021-47469</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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"></Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2023-39180</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.0</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
hid: cp2112: Fix duplicate workqueue initialization
Previously the cp2112 driver called INIT_DELAYED_WORK within
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
workqueue on subsequent IRQ startups following an initial request. This
resulted in a warning in set_work_data in workqueue.c, as well as a rare
NULL dereference within process_one_work in workqueue.c.
Initialize the workqueue within _probe instead.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2023-52853</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.7</BaseScore>
<Vector>AV:L/AC:H/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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:ksmbd: fix UAF issue in ksmbd_tcp_new_connection()The race is between the handling of a new TCP connection andits disconnection. It leads to UAF on `struct tcp_transport` inksmbd_tcp_new_connection() function.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-26592</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.8</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section
between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
worker could collect expired objects and get the released commit lock
within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load
module dependencies, then it goes back to replay the transaction again.
Move it at the end of the abort phase after nft_gc_seq_end() is called.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-26925</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.0</BaseScore>
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:
=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x48
dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
wilc_parse_join_bss_param from connect+0x2c4/0x648
connect from cfg80211_connect+0x30c/0xb74
cfg80211_connect from nl80211_connect+0x860/0xa94
nl80211_connect from genl_rcv_msg+0x3fc/0x59c
genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
netlink_rcv_skb from genl_rcv+0x2c/0x3c
genl_rcv from netlink_unicast+0x3b0/0x550
netlink_unicast from netlink_sendmsg+0x368/0x688
netlink_sendmsg from ____sys_sendmsg+0x190/0x430
____sys_sendmsg from ___sys_sendmsg+0x110/0x158
___sys_sendmsg from sys_sendmsg+0xe8/0x150
sys_sendmsg from ret_fast_syscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-27053</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>3.3</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
media: tc358743: register v4l2 async device only after successful setup
Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-35830</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.0</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
net/rds: fix possible cp null dereference
cp might be null, calling cp-&gt;cp_conn would produce null dereference
[Simon Horman adds:]
Analysis:
* cp is a parameter of __rds_rdma_map and is not reassigned.
* The following call-sites pass a NULL cp argument to __rds_rdma_map()
- rds_get_mr()
- rds_get_mr_for_dest
* Prior to the code above, the following assumes that cp may be NULL
(which is indicative, but could itself be unnecessary)
trans_private = rs-&gt;rs_transport-&gt;get_mr(
sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,
args-&gt;vec.addr, args-&gt;vec.bytes,
need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
* The code modified by this patch is guarded by IS_ERR(trans_private),
where trans_private is assigned as per the previous point in this analysis.
The only implementation of get_mr that I could locate is rds_ib_get_mr()
which can return an ERR_PTR if the conn (4th) argument is NULL.
* ret is set to PTR_ERR(trans_private).
rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
Thus ret may be -ENODEV in which case the code in question will execute.
Conclusion:
* cp may be NULL at the point where this patch adds a check;
this patch does seem to address a possible bug</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-35902</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.0</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULE_STATE_LIVE -&gt;
MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will take
a time. `is_module_text_address()` and `__module_text_address()`
works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
If we use `is_module_text_address()` and `__module_text_address()`
separately, there is a chance that the first one is succeeded but the
next one is failed because module-&gt;state becomes MODULE_STATE_UNFORMED
between those operations.
In `check_kprobe_address_safe()`, if the second `__module_text_address()`
is failed, that is ignored because it expected a kernel_text address.
But it may have failed simply because module-&gt;state has been changed
to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
non-exist module text address (use-after-free).
To fix this problem, we should not use separated `is_module_text_address()`
and `__module_text_address()`, but use only `__module_text_address()`
once and do `try_module_get(module)` which is only available with
MODULE_STATE_LIVE.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-35955</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.0</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
firewire: ohci: mask bus reset interrupts between ISR and bottom half
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.
Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.
irq_handler logs the bus reset interrupt. However, we can&apos;t clear the bus
reset event flag in irq_handler, because we won&apos;t service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with &quot;modprobe firewire_ohci debug=-1&quot; (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.
This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.
irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won&apos;t be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-36950</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
drm/amd/display: Fix division by zero in setup_dsc_config
When slice_height is 0, the division by slice_height in the calculation
of the number of slices will cause a division by zero driver crash. This
leaves the kernel in a state that requires a reboot. This patch adds a
check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
connected via Thunderbolt. The amdgpu driver crashed with this exception
when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor
is connected and the system is rebooted. I believe this is the same
issue reported for 3113.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-36969</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
q-&gt;bands will be assigned to qopt-&gt;bands to execute subsequent code logic
after kmalloc. So the old q-&gt;bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-36978</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-38545</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() { | delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE! | ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-38588</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
xa_erase_irq() to avoid deadlock.</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-38591</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.7</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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">In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
value changed: 0x01 -&gt; 0x03
The line numbers are related to commit dd5a440a31fa (&quot;Linux 6.9-rc7&quot;).
Commit e1d09c2c2f57 (&quot;af_unix: Fix data races around sk-&gt;sk_shutdown.&quot;)
addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-38596</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>2.5</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</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">In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the
new page. Following that, if the operation is successful,
old-&gt;list.next-&gt;prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or
page-&gt;next-&gt;prev might not be equal back to page for some page in the
ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:
[ 190.271762] ------------[ cut here ]------------
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[ 190.271789] Modules linked in: [...]
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[ 190.272023] Code: [...]
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 190.272077] Call Trace:
[ 190.272098] &lt;TASK&gt;
[ 190.272189] ring_buffer_resize+0x2ab/0x460
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
[ 190.272216] tracing_entries_write+0x74/0xc0
[ 190.272225] vfs_write+0xf5/0x420
[ 190.272248] ksys_write+0x67/0xe0
[ 190.272256] do_syscall_64+0x82/0x170
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 190.272373] RIP: 0033:0x7f1bd657d263
[ 190.272381] Code: [...]
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
[ 190.272412] &lt;/TASK&gt;
[ 190.272414] ---[ end trace 0000000000000000 ]---
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
trace_buffer has recording disabled. Recent commit d78ab792705c
(&quot;tracing: Stop current tracer when resizing buffer&quot;) causes that it is
now always the case which makes it more likely to experience this issue.
The window to hit this race is nonetheless very small. To help
reproducing it, one can add a delay loop in rb_get_reader_page():
ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);
if (!ret)
goto spin;
for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++) /* inserted delay loop */
__asm__ __volatile__ (&quot;&quot; : : : &quot;memory&quot;);
rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;
..
---truncated---</Note>
</Notes>
<ReleaseDate>2024-06-28</ReleaseDate>
<CVE>CVE-2024-38601</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.1</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-06-28</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1765</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue View Git Blame Copy Permalink