2648 lines
111 KiB
XML
2648 lines
111 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-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1768</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-SP1.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: SOF: Fix DSP oops stack dump output contents
|
|
|
|
Fix @buf arg given to hex_dump_to_buffer() and stack address used
|
|
in dump error output.(CVE-2021-47381)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.(CVE-2021-47427)
|
|
|
|
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're not trying to reuse a chip
|
|
select that'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:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_powercap_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.(CVE-2023-52696)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: core: Run atomic i2c xfer when !preemptible
|
|
|
|
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
|
|
disabled. However, non-atomic i2c transfers require preemption (e.g. in
|
|
wait_for_completion() while waiting for the DMA).
|
|
|
|
panic() calls preempt_disable_notrace() before calling
|
|
emergency_restart(). Therefore, if an i2c device is used for the
|
|
restart, the xfer should be atomic. This avoids warnings like:
|
|
|
|
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
|
|
[ 12.676926] Voluntary context switch within RCU read-side critical section!
|
|
...
|
|
[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114
|
|
[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
|
|
...
|
|
[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58
|
|
[ 13.001050] machine_restart from panic+0x2a8/0x32c
|
|
|
|
Use !preemptible() instead, which is basically the same check as
|
|
pre-v5.2.(CVE-2023-52791)
|
|
|
|
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:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---(CVE-2024-26852)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: core: Fix unremoved procfs host directory regression
|
|
|
|
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
|
|
directory earlier") fixed a bug related to modules loading/unloading, by
|
|
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
|
|
to a potential duplicate call to the hostdir_rm() routine, since it's also
|
|
called from scsi_host_dev_release(). That triggered a regression report,
|
|
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
|
|
directory removal regression"). The fix just dropped the hostdir_rm() call
|
|
from dev_release().
|
|
|
|
But it happens that this proc directory is created on scsi_host_alloc(),
|
|
and that function "pairs" with scsi_host_dev_release(), while
|
|
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
|
|
reason for removing the proc directory on dev_release() was meant to cover
|
|
cases in which a SCSI host structure was allocated, but the call to
|
|
scsi_add_host() didn't happen. And that pattern happens to exist in some
|
|
error paths, for example.
|
|
|
|
Syzkaller causes that by using USB raw gadget device, error'ing on
|
|
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
|
|
that the BadDevice label leads to a scsi_host_put() after a SCSI host
|
|
allocation, but there's no call to scsi_add_host() in such path. That leads
|
|
to messages like this in dmesg (and a leak of the SCSI host proc
|
|
structure):
|
|
|
|
usb-storage 4-1:87.51: USB Mass Storage device detected
|
|
proc_dir_entry 'scsi/usb-storage' already registered
|
|
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
|
|
|
|
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
|
|
but guard that with the state check for SHOST_CREATED; there is even a
|
|
comment in scsi_host_dev_release() detailing that: such conditional is
|
|
meant for cases where the SCSI host was allocated but there was no calls to
|
|
{add,remove}_host(), like the usb-storage case.
|
|
|
|
This is what we propose here and with that, the error path of usb-storage
|
|
does not trigger the warning anymore.(CVE-2024-26935)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
init/main.c: Fix potential static_command_line memory overflow
|
|
|
|
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
|
|
static_command_line, but the strings copied into static_command_line are
|
|
extra_command_line and command_line, rather than extra_command_line and
|
|
boot_command_line.
|
|
|
|
When strlen(command_line) > strlen(boot_command_line), static_command_line
|
|
will overflow.
|
|
|
|
This patch just recovers strlen(command_line) which was miss-consolidated
|
|
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
|
|
checks for the return value of memblock_alloc*()")(CVE-2024-26988)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to avoid potential panic during recovery
|
|
|
|
During recovery, if FAULT_BLOCK is on, it is possible that
|
|
f2fs_reserve_new_block() will return -ENOSPC during recovery,
|
|
then it may trigger panic.
|
|
|
|
Also, if fault injection rate is 1 and only FAULT_BLOCK fault
|
|
type is on, it may encounter deadloop in loop of block reservation.
|
|
|
|
Let's change as below to fix these issues:
|
|
- remove bug_on() to avoid panic.
|
|
- limit the loop count of block reservation to avoid potential
|
|
deadloop.(CVE-2024-27032)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: Fix clk_core_get NULL dereference
|
|
|
|
It is possible for clk_core_get to dereference a NULL in the following
|
|
sequence:
|
|
|
|
clk_core_get()
|
|
of_clk_get_hw_from_clkspec()
|
|
__of_clk_get_hw_from_provider()
|
|
__clk_get_hw()
|
|
|
|
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
|
|
hw->core.
|
|
|
|
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
|
|
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
|
|
caught the NULL.
|
|
|
|
Reading the description of this function it talks about returning NULL but
|
|
that cannot be so at the moment.
|
|
|
|
Update the function to check for hw before dereferencing it and return NULL
|
|
if hw is NULL.(CVE-2024-27038)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: phy: fix phy_get_internal_delay accessing an empty array
|
|
|
|
The phy_get_internal_delay function could try to access to an empty
|
|
array in the case that the driver is calling phy_get_internal_delay
|
|
without defining delay_values and rx-internal-delay-ps or
|
|
tx-internal-delay-ps is defined to 0 in the device-tree.
|
|
This will lead to "unable to handle kernel NULL pointer dereference at
|
|
virtual address 0". To avoid this kernel oops, the test should be delay
|
|
>= 0. As there is already delay < 0 test just before, the test could
|
|
only be size == 0.(CVE-2024-27047)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
|
|
|
|
The workqueue might still be running, when the driver is stopped. To
|
|
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)
|
|
|
|
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:
|
|
|
|
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
|
|
|
|
It seems that if userspace provides a correct IFA_TARGET_NETNSID value
|
|
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
|
|
returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
|
|
|
|
This is the candidate patch of CVE-2023-47233 :
|
|
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
|
|
|
|
In brcm80211 driver,it starts with the following invoking chain
|
|
to start init a timeout worker:
|
|
|
|
->brcmf_usb_probe
|
|
->brcmf_usb_probe_cb
|
|
->brcmf_attach
|
|
->brcmf_bus_started
|
|
->brcmf_cfg80211_attach
|
|
->wl_init_priv
|
|
->brcmf_init_escan
|
|
->INIT_WORK(&cfg->escan_timeout_work,
|
|
brcmf_cfg80211_escan_timeout_worker);
|
|
|
|
If we disconnect the USB by hotplug, it will call
|
|
brcmf_usb_disconnect to make cleanup. The invoking chain is :
|
|
|
|
brcmf_usb_disconnect
|
|
->brcmf_usb_disconnect_cb
|
|
->brcmf_detach
|
|
->brcmf_cfg80211_detach
|
|
->kfree(cfg);
|
|
|
|
While the timeout woker may still be running. This will cause
|
|
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
|
|
|
|
Fix it by deleting the timer and canceling the worker in
|
|
brcmf_cfg80211_detach.
|
|
|
|
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
|
|
|
|
Otherwise after the GTT bo is released, the GTT and gart space is freed
|
|
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
|
|
and leave valid mapping entry pointing to the stale system page. Then
|
|
if GPU access the gart address mistakely, it will read undefined value
|
|
instead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)
|
|
|
|
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:
|
|
|
|
dyndbg: fix old BUG_ON in >control parser
|
|
|
|
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
|
|
really look), lets make sure by removing it, doing pr_err and return
|
|
-EINVAL instead.(CVE-2024-35947)
|
|
|
|
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->bands will be assigned to qopt->bands to execute subsequent code logic
|
|
after kmalloc. So the old q->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:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)
|
|
|
|
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:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.(CVE-2024-38549)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40(CVE-2024-38555)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
|
|
|
|
The perf tool allows users to create event groups through following
|
|
cmd [1], but the driver does not check whether the array index is out of
|
|
bounds when writing data to the event_group array. If the number of events
|
|
in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write
|
|
overflow of event_group array occurs.
|
|
|
|
Add array index check to fix the possible array out of bounds violation,
|
|
and return directly when write new events are written to array bounds.
|
|
|
|
There are 9 different events in an event_group.
|
|
[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'(CVE-2024-38569)
|
|
|
|
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:
|
|
|
|
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->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->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] <TASK>
|
|
[ 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] </TASK>
|
|
[ 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
|
|
("tracing: Stop current tracer when resizing buffer") 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->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---(CVE-2024-38601)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Allow delete from sockmap/sockhash only if update is allowed
|
|
|
|
We have seen an influx of syzkaller reports where a BPF program attached to
|
|
a tracepoint triggers a locking rule violation by performing a map_delete
|
|
on a sockmap/sockhash.
|
|
|
|
We don't intend to support this artificial use scenario. Extend the
|
|
existing verifier allowed-program-type check for updating sockmap/sockhash
|
|
to also cover deleting from a map.
|
|
|
|
From now on only BPF programs which were previously allowed to update
|
|
sockmap/sockhash can delete from these map types.(CVE-2024-38662)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1.
|
|
|
|
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-1768</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47381</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47427</URL>
|
|
<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-52696</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52791</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-26852</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26921</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26935</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26988</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27032</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27038</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27047</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27052</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-27417</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-31076</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35811</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35817</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-35947</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-38538</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-38549</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38555</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38569</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-38601</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38634</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38662</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47381</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47427</URL>
|
|
<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-52696</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52791</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-26852</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26921</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26935</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26988</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27032</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27038</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27047</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27052</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27053</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27417</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-31076</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35811</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35830</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35947</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-38538</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38545</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38549</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38555</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38569</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38591</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38601</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38634</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38662</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-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.82.0.163.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.82.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.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:
|
|
|
|
ASoC: SOF: Fix DSP oops stack dump output contents
|
|
|
|
Fix @buf arg given to hex_dump_to_buffer() and stack address used
|
|
in dump error output.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47381</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47427</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</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:
|
|
|
|
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're not trying to reuse a chip
|
|
select that'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-SP1</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-1768</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"></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-39180</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_powercap_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52696</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
i2c: core: Run atomic i2c xfer when !preemptible
|
|
|
|
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
|
|
disabled. However, non-atomic i2c transfers require preemption (e.g. in
|
|
wait_for_completion() while waiting for the DMA).
|
|
|
|
panic() calls preempt_disable_notrace() before calling
|
|
emergency_restart(). Therefore, if an i2c device is used for the
|
|
restart, the xfer should be atomic. This avoids warnings like:
|
|
|
|
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
|
|
[ 12.676926] Voluntary context switch within RCU read-side critical section!
|
|
...
|
|
[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114
|
|
[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
|
|
...
|
|
[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58
|
|
[ 13.001050] machine_restart from panic+0x2a8/0x32c
|
|
|
|
Use !preemptible() instead, which is basically the same check as
|
|
pre-v5.2.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</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:
|
|
|
|
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-SP1</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-1768</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: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-SP1</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-1768</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:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-26852</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
inet: inet_defrag: prevent sk release while still in use
|
|
|
|
ip_local_out() and other functions can pass skb->sk as function argument.
|
|
|
|
If the skb is a fragment and reassembly happens before such function call
|
|
returns, the sk must not be released.
|
|
|
|
This affects skb fragments reassembled via netfilter or similar
|
|
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
|
|
|
|
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
|
|
Calling ip_defrag() in output path is also implying skb_orphan(),
|
|
which is buggy because output path relies on sk not disappearing.
|
|
|
|
A relevant old patch about the issue was :
|
|
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
|
|
|
|
[..]
|
|
|
|
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
|
|
inet socket, not an arbitrary one.
|
|
|
|
If we orphan the packet in ipvlan, then downstream things like FQ
|
|
packet scheduler will not work properly.
|
|
|
|
We need to change ip_defrag() to only use skb_orphan() when really
|
|
needed, ie whenever frag_list is going to be used.
|
|
|
|
Eric suggested to stash sk in fragment queue and made an initial patch.
|
|
However there is a problem with this:
|
|
|
|
If skb is refragmented again right after, ip_do_fragment() will copy
|
|
head->sk to the new fragments, and sets up destructor to sock_wfree.
|
|
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
|
|
fully reassembled skb, else wmem will underflow.
|
|
|
|
This change moves the orphan down into the core, to last possible moment.
|
|
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
|
|
offset into the FRAG_CB, else skb->sk gets clobbered.
|
|
|
|
This allows to delay the orphaning long enough to learn if the skb has
|
|
to be queued or if the skb is completing the reasm queue.
|
|
|
|
In the former case, things work as before, skb is orphaned. This is
|
|
safe because skb gets queued/stolen and won't continue past reasm engine.
|
|
|
|
In the latter case, we will steal the skb->sk reference, reattach it to
|
|
the head skb, and fix up wmem accouting when inet_frag inflates truesize.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-26921</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
scsi: core: Fix unremoved procfs host directory regression
|
|
|
|
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
|
|
directory earlier") fixed a bug related to modules loading/unloading, by
|
|
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
|
|
to a potential duplicate call to the hostdir_rm() routine, since it's also
|
|
called from scsi_host_dev_release(). That triggered a regression report,
|
|
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
|
|
directory removal regression"). The fix just dropped the hostdir_rm() call
|
|
from dev_release().
|
|
|
|
But it happens that this proc directory is created on scsi_host_alloc(),
|
|
and that function "pairs" with scsi_host_dev_release(), while
|
|
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
|
|
reason for removing the proc directory on dev_release() was meant to cover
|
|
cases in which a SCSI host structure was allocated, but the call to
|
|
scsi_add_host() didn't happen. And that pattern happens to exist in some
|
|
error paths, for example.
|
|
|
|
Syzkaller causes that by using USB raw gadget device, error'ing on
|
|
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
|
|
that the BadDevice label leads to a scsi_host_put() after a SCSI host
|
|
allocation, but there's no call to scsi_add_host() in such path. That leads
|
|
to messages like this in dmesg (and a leak of the SCSI host proc
|
|
structure):
|
|
|
|
usb-storage 4-1:87.51: USB Mass Storage device detected
|
|
proc_dir_entry 'scsi/usb-storage' already registered
|
|
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
|
|
|
|
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
|
|
but guard that with the state check for SHOST_CREATED; there is even a
|
|
comment in scsi_host_dev_release() detailing that: such conditional is
|
|
meant for cases where the SCSI host was allocated but there was no calls to
|
|
{add,remove}_host(), like the usb-storage case.
|
|
|
|
This is what we propose here and with that, the error path of usb-storage
|
|
does not trigger the warning anymore.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-26935</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
init/main.c: Fix potential static_command_line memory overflow
|
|
|
|
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
|
|
static_command_line, but the strings copied into static_command_line are
|
|
extra_command_line and command_line, rather than extra_command_line and
|
|
boot_command_line.
|
|
|
|
When strlen(command_line) > strlen(boot_command_line), static_command_line
|
|
will overflow.
|
|
|
|
This patch just recovers strlen(command_line) which was miss-consolidated
|
|
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
|
|
checks for the return value of memblock_alloc*()")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-26988</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
f2fs: fix to avoid potential panic during recovery
|
|
|
|
During recovery, if FAULT_BLOCK is on, it is possible that
|
|
f2fs_reserve_new_block() will return -ENOSPC during recovery,
|
|
then it may trigger panic.
|
|
|
|
Also, if fault injection rate is 1 and only FAULT_BLOCK fault
|
|
type is on, it may encounter deadloop in loop of block reservation.
|
|
|
|
Let's change as below to fix these issues:
|
|
- remove bug_on() to avoid panic.
|
|
- limit the loop count of block reservation to avoid potential
|
|
deadloop.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27032</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
clk: Fix clk_core_get NULL dereference
|
|
|
|
It is possible for clk_core_get to dereference a NULL in the following
|
|
sequence:
|
|
|
|
clk_core_get()
|
|
of_clk_get_hw_from_clkspec()
|
|
__of_clk_get_hw_from_provider()
|
|
__clk_get_hw()
|
|
|
|
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
|
|
hw->core.
|
|
|
|
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
|
|
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
|
|
caught the NULL.
|
|
|
|
Reading the description of this function it talks about returning NULL but
|
|
that cannot be so at the moment.
|
|
|
|
Update the function to check for hw before dereferencing it and return NULL
|
|
if hw is NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27038</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
net: phy: fix phy_get_internal_delay accessing an empty array
|
|
|
|
The phy_get_internal_delay function could try to access to an empty
|
|
array in the case that the driver is calling phy_get_internal_delay
|
|
without defining delay_values and rx-internal-delay-ps or
|
|
tx-internal-delay-ps is defined to 0 in the device-tree.
|
|
This will lead to "unable to handle kernel NULL pointer dereference at
|
|
virtual address 0". To avoid this kernel oops, the test should be delay
|
|
>= 0. As there is already delay < 0 test just before, the test could
|
|
only be size == 0.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27047</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
|
|
|
|
The workqueue might still be running, when the driver is stopped. To
|
|
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27052</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/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-1768</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:
|
|
|
|
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-SP1</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-1768</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:
|
|
|
|
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
|
|
|
|
It seems that if userspace provides a correct IFA_TARGET_NETNSID value
|
|
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
|
|
returns -EINVAL with an elevated "struct net" refcount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27417</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</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:
|
|
|
|
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
|
|
|
|
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
|
|
interrupt affinity reconfiguration via procfs. Instead, the change is
|
|
deferred until the next instance of the interrupt being triggered on the
|
|
original CPU.
|
|
|
|
When the interrupt next triggers on the original CPU, the new affinity is
|
|
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
|
|
but the old vector on the original CPU remains and is not immediately
|
|
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
|
|
process is delayed until the next trigger of the interrupt on the new CPU.
|
|
|
|
Upon the subsequent triggering of the interrupt on the new CPU,
|
|
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
|
|
remains online. Subsequently, the timer on the old CPU iterates over its
|
|
vector_cleanup list, reclaiming old vectors.
|
|
|
|
However, a rare scenario arises if the old CPU is outgoing before the
|
|
interrupt triggers again on the new CPU.
|
|
|
|
In that case irq_force_complete_move() is not invoked on the outgoing CPU
|
|
to reclaim the old apicd->prev_vector because the interrupt isn't currently
|
|
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
|
|
though __vector_schedule_cleanup() is later called on the new CPU, it
|
|
doesn't reclaim apicd->prev_vector; instead, it simply resets both
|
|
apicd->move_in_progress and apicd->prev_vector to 0.
|
|
|
|
As a result, the vector remains unreclaimed in vector_matrix, leading to a
|
|
CPU vector leak.
|
|
|
|
To address this issue, move the invocation of irq_force_complete_move()
|
|
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
|
|
interrupt is currently or used to be affine to the outgoing CPU.
|
|
|
|
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
|
|
following a warning message, although theoretically it should never see
|
|
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-31076</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</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:
|
|
|
|
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
|
|
|
|
This is the candidate patch of CVE-2023-47233 :
|
|
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
|
|
|
|
In brcm80211 driver,it starts with the following invoking chain
|
|
to start init a timeout worker:
|
|
|
|
->brcmf_usb_probe
|
|
->brcmf_usb_probe_cb
|
|
->brcmf_attach
|
|
->brcmf_bus_started
|
|
->brcmf_cfg80211_attach
|
|
->wl_init_priv
|
|
->brcmf_init_escan
|
|
->INIT_WORK(&cfg->escan_timeout_work,
|
|
brcmf_cfg80211_escan_timeout_worker);
|
|
|
|
If we disconnect the USB by hotplug, it will call
|
|
brcmf_usb_disconnect to make cleanup. The invoking chain is :
|
|
|
|
brcmf_usb_disconnect
|
|
->brcmf_usb_disconnect_cb
|
|
->brcmf_detach
|
|
->brcmf_cfg80211_detach
|
|
->kfree(cfg);
|
|
|
|
While the timeout woker may still be running. This will cause
|
|
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
|
|
|
|
Fix it by deleting the timer and canceling the worker in
|
|
brcmf_cfg80211_detach.
|
|
|
|
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-35811</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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: amdgpu_ttm_gart_bind set gtt bound flag
|
|
|
|
Otherwise after the GTT bo is released, the GTT and gart space is freed
|
|
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
|
|
and leave valid mapping entry pointing to the stale system page. Then
|
|
if GPU access the gart address mistakely, it will read undefined value
|
|
instead page fault, harder to debug and reproduce the real issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-35817</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</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:
|
|
|
|
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-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dyndbg: fix old BUG_ON in >control parser
|
|
|
|
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
|
|
really look), lets make sure by removing it, doing pr_err and return
|
|
-EINVAL instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-35947</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" 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-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" 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->bands will be assigned to qopt->bands to execute subsequent code logic
|
|
after kmalloc. So the old q->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-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38538</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" 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-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
|
|
|
|
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
|
|
of 0 bytes. Currently, no such check exists and the kernel will panic if
|
|
a userspace application attempts to allocate a 0x0 GBM buffer.
|
|
|
|
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
|
|
verifying that we now return EINVAL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38549</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Discard command completions in internal error
|
|
|
|
Fix use after free when FW completion arrives while device is in
|
|
internal error state. Avoid calling completion handler in this case,
|
|
since the device will flush the command interface and trigger all
|
|
completions manually.
|
|
|
|
Kernel log:
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
...
|
|
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
? __warn+0x79/0x120
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
? report_bug+0x17c/0x190
|
|
? handle_bug+0x3c/0x60
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0xd8/0xe0
|
|
cmd_ent_put+0x13b/0x160 [mlx5_core]
|
|
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
|
|
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
|
|
notifier_call_chain+0x35/0xb0
|
|
atomic_notifier_call_chain+0x16/0x20
|
|
irq_int_handler+0x19/0x30 [mlx5_core]
|
|
__handle_irq_event_percpu+0x4b/0x160
|
|
handle_irq_event+0x2e/0x80
|
|
handle_edge_irq+0x98/0x230
|
|
__common_interrupt+0x3b/0xa0
|
|
common_interrupt+0x7b/0xa0
|
|
</IRQ>
|
|
<TASK>
|
|
asm_common_interrupt+0x22/0x40</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38555</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
|
|
|
|
The perf tool allows users to create event groups through following
|
|
cmd [1], but the driver does not check whether the array index is out of
|
|
bounds when writing data to the event_group array. If the number of events
|
|
in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write
|
|
overflow of event_group array occurs.
|
|
|
|
Add array index check to fix the possible array out of bounds violation,
|
|
and return directly when write new events are written to array bounds.
|
|
|
|
There are 9 different events in an event_group.
|
|
[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38569</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" 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-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" 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->list.prev->next to point it to the
|
|
new page. Following that, if the operation is successful,
|
|
old->list.next->prev gets updated too. This means the underlying
|
|
doubly-linked list is temporarily inconsistent, page->prev->next or
|
|
page->next->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] <TASK>
|
|
[ 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] </TASK>
|
|
[ 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
|
|
("tracing: Stop current tracer when resizing buffer") 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->reader_page);
|
|
if (!ret)
|
|
goto spin;
|
|
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
|
|
__asm__ __volatile__ ("" : : : "memory");
|
|
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
|
|
|
|
..
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38601</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
|
|
|
|
uart_handle_cts_change() has to be called with port lock taken,
|
|
Since we run it in a separate work, the lock may not be taken at
|
|
the time of running. Make sure that it's taken by explicitly doing
|
|
that. Without it we got a splat:
|
|
|
|
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
Workqueue: max3100-0 max3100_work [max3100]
|
|
RIP: 0010:uart_handle_cts_change+0xa6/0xb0
|
|
...
|
|
max3100_handlerx+0xc5/0x110 [max3100]
|
|
max3100_work+0x12a/0x340 [max3100]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38634</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Allow delete from sockmap/sockhash only if update is allowed
|
|
|
|
We have seen an influx of syzkaller reports where a BPF program attached to
|
|
a tracepoint triggers a locking rule violation by performing a map_delete
|
|
on a sockmap/sockhash.
|
|
|
|
We don't intend to support this artificial use scenario. Extend the
|
|
existing verifier allowed-program-type check for updating sockmap/sockhash
|
|
to also cover deleting from a map.
|
|
|
|
From now on only BPF programs which were previously allowed to update
|
|
sockmap/sockhash can delete from these map types.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38662</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1768</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |