2058 lines
91 KiB
XML
2058 lines
91 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-20.03-LTS-SP4</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-1895</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-26</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-26</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-26</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-26</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</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:
|
|
|
|
nfc: fix segfault in nfc_genl_dump_devices_done
|
|
|
|
When kmalloc in nfc_genl_dump_devices() fails then
|
|
nfc_genl_dump_devices_done() segfaults as below
|
|
|
|
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
|
|
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
|
|
Workqueue: events netlink_sock_destruct_work
|
|
RIP: 0010:klist_iter_exit+0x26/0x80
|
|
Call Trace:
|
|
<TASK>
|
|
class_dev_iter_exit+0x15/0x20
|
|
nfc_genl_dump_devices_done+0x3b/0x50
|
|
genl_lock_done+0x84/0xd0
|
|
netlink_sock_destruct+0x8f/0x270
|
|
__sk_destruct+0x64/0x3b0
|
|
sk_destruct+0xa8/0xd0
|
|
__sk_free+0x2e8/0x3d0
|
|
sk_free+0x51/0x90
|
|
netlink_sock_destruct_work+0x1c/0x20
|
|
process_one_work+0x411/0x710
|
|
worker_thread+0x6fd/0xa80(CVE-2021-47612)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
|
|
|
|
kobject_init_and_add() takes reference even when it fails.
|
|
According to the doc of kobject_init_and_add()?
|
|
|
|
If this function returns an error, kobject_put() must be called to
|
|
properly clean up the memory associated with the object.
|
|
|
|
Fix memory leak by calling kobject_put().(CVE-2022-48775)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-rdma: fix possible use-after-free in transport error_recovery work
|
|
|
|
While nvme_rdma_submit_async_event_work is checking the ctrl and queue
|
|
state before preparing the AER command and scheduling io_work, in order
|
|
to fully prevent a race where this check is not reliable the error
|
|
recovery work must flush async_event_work before continuing to destroy
|
|
the admin queue after setting the ctrl state to RESETTING such that
|
|
there is no race .submit_async_event and the error recovery handler
|
|
itself changing the ctrl state.(CVE-2022-48788)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
|
|
|
|
The syzbot fuzzer found a use-after-free bug:
|
|
|
|
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
|
|
Read of size 8 at addr ffff88802b934098 by task udevd/3689
|
|
|
|
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
|
|
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
|
|
__kasan_report mm/kasan/report.c:442 [inline]
|
|
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
|
|
dev_uevent+0x712/0x780 drivers/base/core.c:2320
|
|
uevent_show+0x1b8/0x380 drivers/base/core.c:2391
|
|
dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
|
|
|
|
Although the bug manifested in the driver core, the real cause was a
|
|
race with the gadget core. dev_uevent() does:
|
|
|
|
if (dev->driver)
|
|
add_uevent_var(env, "DRIVER=%s", dev->driver->name);
|
|
|
|
and between the test and the dereference of dev->driver, the gadget
|
|
core sets dev->driver to NULL.
|
|
|
|
The race wouldn't occur if the gadget core registered its devices on
|
|
a real bus, using the standard synchronization techniques of the
|
|
driver core. However, it's not necessary to make such a large change
|
|
in order to fix this bug; all we need to do is make sure that
|
|
udc->dev.driver is always NULL.
|
|
|
|
In fact, there is no reason for udc->dev.driver ever to be set to
|
|
anything, let alone to the value it currently gets: the address of the
|
|
gadget's driver. After all, a gadget driver only knows how to manage
|
|
a gadget, not how to manage a UDC.
|
|
|
|
This patch simply removes the statements in the gadget core that touch
|
|
udc->dev.driver.(CVE-2022-48838)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sctp: fix kernel-infoleak for SCTP sockets
|
|
|
|
syzbot reported a kernel infoleak [1] of 4 bytes.
|
|
|
|
After analysis, it turned out r->idiag_expires is not initialized
|
|
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
|
|
|
|
Make sure to clear idiag_timer/idiag_retrans/idiag_expires
|
|
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
|
|
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
copyout lib/iov_iter.c:154 [inline]
|
|
_copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
|
|
copy_to_iter include/linux/uio.h:162 [inline]
|
|
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
|
|
__skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
|
|
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
|
|
netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
|
|
sock_recvmsg_nosec net/socket.c:948 [inline]
|
|
sock_recvmsg net/socket.c:966 [inline]
|
|
__sys_recvfrom+0x795/0xa10 net/socket.c:2097
|
|
__do_sys_recvfrom net/socket.c:2115 [inline]
|
|
__se_sys_recvfrom net/socket.c:2111 [inline]
|
|
__x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slab.h:737 [inline]
|
|
slab_alloc_node mm/slub.c:3247 [inline]
|
|
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
|
|
kmalloc_reserve net/core/skbuff.c:354 [inline]
|
|
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
|
|
alloc_skb include/linux/skbuff.h:1158 [inline]
|
|
netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
|
|
__netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
|
|
netlink_dump_start include/linux/netlink.h:254 [inline]
|
|
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
|
|
sock_diag_rcv_msg+0x24a/0x620
|
|
netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
|
|
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
|
|
netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
|
|
netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
|
|
sock_sendmsg_nosec net/socket.c:705 [inline]
|
|
sock_sendmsg net/socket.c:725 [inline]
|
|
sock_write_iter+0x594/0x690 net/socket.c:1061
|
|
do_iter_readv_writev+0xa7f/0xc70
|
|
do_iter_write+0x52c/0x1500 fs/read_write.c:851
|
|
vfs_writev fs/read_write.c:924 [inline]
|
|
do_writev+0x645/0xe00 fs/read_write.c:967
|
|
__do_sys_writev fs/read_write.c:1040 [inline]
|
|
__se_sys_writev fs/read_write.c:1037 [inline]
|
|
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Bytes 68-71 of 2508 are uninitialized
|
|
Memory access of size 2508 starts at ffff888114f9b000
|
|
Data copied to user address 00007f7fe09ff2e0
|
|
|
|
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-48855)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
|
|
|
|
The of_find_compatible_node() function returns a node pointer with
|
|
refcount incremented, We should use of_node_put() on it when done
|
|
Add the missing of_node_put() to release the refcount.(CVE-2022-48856)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tipc: fix kernel panic when enabling bearer
|
|
|
|
When enabling a bearer on a node, a kernel panic is observed:
|
|
|
|
[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
|
|
...
|
|
[ 4.520030] Call Trace:
|
|
[ 4.520689] <IRQ>
|
|
[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]
|
|
[ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]
|
|
[ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]
|
|
[ 4.525292] tipc_rcv+0x5da/0x730 [tipc]
|
|
[ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0
|
|
[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]
|
|
[ 4.528737] __netif_receive_skb_list_core+0x20b/0x260
|
|
[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0
|
|
[ 4.531450] ? dev_gro_receive+0x4c2/0x680
|
|
[ 4.532512] napi_complete_done+0x6f/0x180
|
|
[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]
|
|
...
|
|
|
|
The node in question is receiving activate messages in another
|
|
thread after changing bearer status to allow message sending/
|
|
receiving in current thread:
|
|
|
|
thread 1 | thread 2
|
|
-------- | --------
|
|
|
|
|
tipc_enable_bearer() |
|
|
test_and_set_bit_lock() |
|
|
tipc_bearer_xmit_skb() |
|
|
| tipc_l2_rcv_msg()
|
|
| tipc_rcv()
|
|
| __tipc_node_link_up()
|
|
| tipc_link_build_state_msg()
|
|
| tipc_link_build_proto_msg()
|
|
| tipc_mon_prep()
|
|
| {
|
|
| ...
|
|
| // null-pointer dereference
|
|
| u16 gen = mon->dom_gen;
|
|
| ...
|
|
| }
|
|
// Not being executed yet |
|
|
tipc_mon_create() |
|
|
{ |
|
|
... |
|
|
// allocate |
|
|
mon = kzalloc(); |
|
|
... |
|
|
} |
|
|
|
|
Monitoring pointer in thread 2 is dereferenced before monitoring data
|
|
is allocated in thread 1. This causes kernel panic.
|
|
|
|
This commit fixes it by allocating the monitoring data before enabling
|
|
the bearer to receive messages.(CVE-2022-48865)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: fix possible dead-lock in nr_rt_ioctl()
|
|
|
|
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
|
|
|
|
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
|
|
|
|
[1]
|
|
WARNING: possible circular locking dependency detected
|
|
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
|
|
------------------------------------------------------
|
|
syz-executor350/5129 is trying to acquire lock:
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
|
|
|
|
but task is already holding lock:
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
|
|
|
|
which lock already depends on the new lock.
|
|
|
|
the existing dependency chain (in reverse order) is:
|
|
|
|
-> #1 (nr_node_list_lock){+...}-{2:2}:
|
|
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
|
|
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
|
|
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
|
|
spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
nr_remove_node net/netrom/nr_route.c:299 [inline]
|
|
nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
|
|
nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
|
|
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
|
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
-> #0 (&nr_node->node_lock){+...}-{2:2}:
|
|
check_prev_add kernel/locking/lockdep.c:3134 [inline]
|
|
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
|
|
validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
|
|
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
|
|
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
|
|
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
|
|
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
|
|
spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
nr_node_lock include/net/netrom.h:152 [inline]
|
|
nr_dec_obs net/netrom/nr_route.c:464 [inline]
|
|
nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
|
|
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
|
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
other info that might help us debug this:
|
|
|
|
Possible unsafe locking scenario:
|
|
|
|
CPU0 CPU1
|
|
---- ----
|
|
lock(nr_node_list_lock);
|
|
lock(&nr_node->node_lock);
|
|
lock(nr_node_list_lock);
|
|
lock(&nr_node->node_lock);
|
|
|
|
*** DEADLOCK ***
|
|
|
|
1 lock held by syz-executor350/5129:
|
|
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
|
|
#0: ffffffff8f70
|
|
---truncated---(CVE-2024-38589)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
|
|
|
|
Using completion_done to determine whether the caller has gone
|
|
away only works after a complete call. Furthermore it's still
|
|
possible that the caller has not yet called wait_for_completion,
|
|
resulting in another potential UAF.
|
|
|
|
Fix this by making the caller use cancel_work_sync and then freeing
|
|
the memory safely.(CVE-2024-39493)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ima: Fix use-after-free on a dentry's dname.name
|
|
|
|
->d_name.name can change on rename and the earlier value can be freed;
|
|
there are conditions sufficient to stabilize it (->d_lock on dentry,
|
|
->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,
|
|
rename_lock), but none of those are met at any of the sites. Take a stable
|
|
snapshot of the name instead.(CVE-2024-39494)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vmci: prevent speculation leaks by sanitizing event in event_deliver()
|
|
|
|
Coverity spotted that event_msg is controlled by user-space,
|
|
event_msg->event_data.event is passed to event_deliver() and used
|
|
as an index without sanitization.
|
|
|
|
This change ensures that the event index is sanitized to mitigate any
|
|
possibility of speculative information leaks.
|
|
|
|
This bug was discovered and resolved using Coverity Static Analysis
|
|
Security Testing (SAST) by Synopsys, Inc.
|
|
|
|
Only compile tested, no access to HW.(CVE-2024-39499)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
|
|
|
|
The syzbot fuzzer found that the interrupt-URB completion callback in
|
|
the cdc-wdm driver was taking too long, and the driver's immediate
|
|
resubmission of interrupt URBs with -EPROTO status combined with the
|
|
dummy-hcd emulation to cause a CPU lockup:
|
|
|
|
cdc_wdm 1-1:1.0: nonzero urb status received: -71
|
|
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
|
|
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
|
|
CPU#0 Utilization every 4s during lockup:
|
|
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
|
|
Modules linked in:
|
|
irq event stamp: 73096
|
|
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
|
|
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
|
|
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
|
|
softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
|
|
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
|
|
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
|
|
Testing showed that the problem did not occur if the two error
|
|
messages -- the first two lines above -- were removed; apparently adding
|
|
material to the kernel log takes a surprisingly large amount of time.
|
|
|
|
In any case, the best approach for preventing these lockups and to
|
|
avoid spamming the log with thousands of error messages per second is
|
|
to ratelimit the two dev_err() calls. Therefore we replace them with
|
|
dev_err_ratelimited().(CVE-2024-40904)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
|
|
|
|
The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to
|
|
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
|
|
softirq context. However using only spin_lock() to get sta->ps_lock in
|
|
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
|
|
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
|
|
take this same lock ending in deadlock. Below is an example of rcu stall
|
|
that arises in such situation.
|
|
|
|
rcu: INFO: rcu_sched self-detected stall on CPU
|
|
rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
|
|
rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)
|
|
CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742
|
|
Hardware name: RPT (r1) (DT)
|
|
pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : queued_spin_lock_slowpath+0x58/0x2d0
|
|
lr : invoke_tx_handlers_early+0x5b4/0x5c0
|
|
sp : ffff00001ef64660
|
|
x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
|
|
x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
|
|
x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
|
|
x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
|
|
x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
|
|
x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
|
|
x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
|
|
x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
|
|
x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
|
|
Call trace:
|
|
queued_spin_lock_slowpath+0x58/0x2d0
|
|
ieee80211_tx+0x80/0x12c
|
|
ieee80211_tx_pending+0x110/0x278
|
|
tasklet_action_common.constprop.0+0x10c/0x144
|
|
tasklet_action+0x20/0x28
|
|
_stext+0x11c/0x284
|
|
____do_softirq+0xc/0x14
|
|
call_on_irq_stack+0x24/0x34
|
|
do_softirq_own_stack+0x18/0x20
|
|
do_softirq+0x74/0x7c
|
|
__local_bh_enable_ip+0xa0/0xa4
|
|
_ieee80211_wake_txqs+0x3b0/0x4b8
|
|
__ieee80211_wake_queue+0x12c/0x168
|
|
ieee80211_add_pending_skbs+0xec/0x138
|
|
ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
|
|
ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
|
|
ieee80211_mps_sta_status_update+0x18/0x24
|
|
sta_apply_parameters+0x3bc/0x4c0
|
|
ieee80211_change_station+0x1b8/0x2dc
|
|
nl80211_set_station+0x444/0x49c
|
|
genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
|
|
genl_rcv_msg+0x1b0/0x244
|
|
netlink_rcv_skb+0x38/0x10c
|
|
genl_rcv+0x34/0x48
|
|
netlink_unicast+0x254/0x2bc
|
|
netlink_sendmsg+0x190/0x3b4
|
|
____sys_sendmsg+0x1e8/0x218
|
|
___sys_sendmsg+0x68/0x8c
|
|
__sys_sendmsg+0x44/0x84
|
|
__arm64_sys_sendmsg+0x20/0x28
|
|
do_el0_svc+0x6c/0xe8
|
|
el0_svc+0x14/0x48
|
|
el0t_64_sync_handler+0xb0/0xb4
|
|
el0t_64_sync+0x14c/0x150
|
|
|
|
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
|
|
on the same CPU that is holding the lock.(CVE-2024-40912)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
|
|
|
|
In some versions of cfg80211, the ssids poinet might be a valid one even
|
|
though n_ssids is 0. Accessing the pointer in this case will cuase an
|
|
out-of-bound access. Fix this by checking n_ssids first.(CVE-2024-40929)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/exynos/vidi: fix memory leak in .get_modes()
|
|
|
|
The duplicated EDID is never freed. Fix it.(CVE-2024-40932)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: mvm: don't read past the mfuart notifcation
|
|
|
|
In case the firmware sends a notification that claims it has more data
|
|
than it has, we will read past that was allocated for the notification.
|
|
Remove the print of the buffer, we won't see it by default. If needed,
|
|
we can see the content with tracing.
|
|
|
|
This was reported by KFENCE.(CVE-2024-40941)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix races between hole punching and AIO+DIO
|
|
|
|
After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
|
|
fstests/generic/300 become from always failed to sometimes failed:
|
|
|
|
========================================================================
|
|
[ 473.293420 ] run fstests generic/300
|
|
|
|
[ 475.296983 ] JBD2: Ignoring recovery information on journal
|
|
[ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
|
|
[ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
|
|
[ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
|
|
[ 494.292018 ] OCFS2: File system is now read-only.
|
|
[ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
|
|
[ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
|
|
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
|
|
=========================================================================
|
|
|
|
In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
|
|
extents to a list. extents are also inserted into extent tree in
|
|
ocfs2_write_begin_nolock. Then another thread call fallocate to puch a
|
|
hole at one of the unwritten extent. The extent at cpos was removed by
|
|
ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list
|
|
found there is no such extent at the cpos.
|
|
|
|
T1 T2 T3
|
|
inode lock
|
|
...
|
|
insert extents
|
|
...
|
|
inode unlock
|
|
ocfs2_fallocate
|
|
__ocfs2_change_file_space
|
|
inode lock
|
|
lock ip_alloc_sem
|
|
ocfs2_remove_inode_range inode
|
|
ocfs2_remove_btree_range
|
|
ocfs2_remove_extent
|
|
^---remove the extent at cpos 78723
|
|
...
|
|
unlock ip_alloc_sem
|
|
inode unlock
|
|
ocfs2_dio_end_io
|
|
ocfs2_dio_end_io_write
|
|
lock ip_alloc_sem
|
|
ocfs2_mark_extent_written
|
|
ocfs2_change_extent_flag
|
|
ocfs2_search_extent_list
|
|
^---failed to find extent
|
|
...
|
|
unlock ip_alloc_sem
|
|
|
|
In most filesystems, fallocate is not compatible with racing with AIO+DIO,
|
|
so fix it by adding to wait for all dio before fallocate/punch_hole like
|
|
ext4.(CVE-2024-40943)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
MIPS: Octeon: Add PCIe link status check
|
|
|
|
The standard PCIe configuration read-write interface is used to
|
|
access the configuration space of the peripheral PCIe devices
|
|
of the mips processor after the PCIe link surprise down, it can
|
|
generate kernel panic caused by "Data bus error". So it is
|
|
necessary to add PCIe link status check for system protection.
|
|
When the PCIe link is down or in training, assigning a value
|
|
of 0 to the configuration address can prevent read-write behavior
|
|
to the configuration space of peripheral PCIe devices, thereby
|
|
preventing kernel panic.(CVE-2024-40968)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/pseries: Enforce hcall result buffer validity and size
|
|
|
|
plpar_hcall(), plpar_hcall9(), and related functions expect callers to
|
|
provide valid result buffers of certain minimum size. Currently this
|
|
is communicated only through comments in the code and the compiler has
|
|
no idea.
|
|
|
|
For example, if I write a bug like this:
|
|
|
|
long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
|
|
plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);
|
|
|
|
This compiles with no diagnostics emitted, but likely results in stack
|
|
corruption at runtime when plpar_hcall9() stores results past the end
|
|
of the array. (To be clear this is a contrived example and I have not
|
|
found a real instance yet.)
|
|
|
|
To make this class of error less likely, we can use explicitly-sized
|
|
array parameters instead of pointers in the declarations for the hcall
|
|
APIs. When compiled with -Warray-bounds[1], the code above now
|
|
provokes a diagnostic like this:
|
|
|
|
error: array argument is too small;
|
|
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
|
|
60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
|
|
| ^ ~~~~~~
|
|
|
|
[1] Enabled for LLVM builds but not GCC for now. See commit
|
|
0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
|
|
related changes.(CVE-2024-40974)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
|
|
|
|
Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
|
|
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
|
|
purpose of this commit was to stop memory mappings for operation
|
|
regions from overlapping page boundaries, as it can trigger warnings
|
|
if different page attributes are present.
|
|
|
|
However, it was found that when this situation arises, mapping
|
|
continues until the boundary's end, but there is still an attempt to
|
|
read/write the entire length of the map, leading to a NULL pointer
|
|
deference. For example, if a four-byte mapping request is made but
|
|
only one byte is mapped because it hits the current page boundary's
|
|
end, a four-byte read/write attempt is still made, resulting in a NULL
|
|
pointer deference.
|
|
|
|
Instead, map the entire length, as the ACPI specification does not
|
|
mandate that it must be within the same page boundary. It is
|
|
permissible for it to be mapped across different regions.(CVE-2024-40984)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: fix UBSAN warning in kv_dpm.c
|
|
|
|
Adds bounds check for sumo_vid_mapping_entry.(CVE-2024-40987)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netpoll: Fix race condition in netpoll_owner_active
|
|
|
|
KCSAN detected a race condition in netpoll:
|
|
|
|
BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
|
|
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
|
|
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
|
|
<snip>
|
|
read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
|
|
netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
|
|
netpoll_send_udp (net/core/netpoll.c:?)
|
|
<snip>
|
|
value changed: 0x0000000a -> 0xffffffff
|
|
|
|
This happens because netpoll_owner_active() needs to check if the
|
|
current CPU is the owner of the lock, touching napi->poll_owner
|
|
non atomically. The ->poll_owner field contains the current CPU holding
|
|
the lock.
|
|
|
|
Use an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: avoid too many retransmit packets
|
|
|
|
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
|
|
retracted its window to zero, tcp_retransmit_timer() can
|
|
retransmit a packet every two jiffies (2 ms for HZ=1000),
|
|
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
|
|
|
|
The fix is to make sure tcp_rtx_probe0_timed_out() takes
|
|
icsk->icsk_user_timeout into account.
|
|
|
|
Before blamed commit, the socket would not timeout after
|
|
icsk->icsk_user_timeout, but would use standard exponential
|
|
backoff for the retransmits.
|
|
|
|
Also worth noting that before commit e89688e3e978 ("net: tcp:
|
|
fix unexcepted socket die when snd_wnd is 0"), the issue
|
|
would last 2 minutes instead of 4.(CVE-2024-41007)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
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/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47612</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48775</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48788</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48838</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48855</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48856</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48865</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38589</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39493</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39494</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39499</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40904</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40912</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40929</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40932</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40941</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40943</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40968</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40974</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40984</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40987</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41005</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41007</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47612</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48775</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48788</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48838</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48855</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48856</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48865</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38589</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39493</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39494</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39499</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40904</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40912</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40929</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40932</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40941</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40943</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40968</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40974</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40984</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40987</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41005</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41007</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2407.5.0.0287" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.5.0.0287.oe2003sp4.src.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:
|
|
|
|
nfc: fix segfault in nfc_genl_dump_devices_done
|
|
|
|
When kmalloc in nfc_genl_dump_devices() fails then
|
|
nfc_genl_dump_devices_done() segfaults as below
|
|
|
|
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
|
|
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
|
|
Workqueue: events netlink_sock_destruct_work
|
|
RIP: 0010:klist_iter_exit+0x26/0x80
|
|
Call Trace:
|
|
<TASK>
|
|
class_dev_iter_exit+0x15/0x20
|
|
nfc_genl_dump_devices_done+0x3b/0x50
|
|
genl_lock_done+0x84/0xd0
|
|
netlink_sock_destruct+0x8f/0x270
|
|
__sk_destruct+0x64/0x3b0
|
|
sk_destruct+0xa8/0xd0
|
|
__sk_free+0x2e8/0x3d0
|
|
sk_free+0x51/0x90
|
|
netlink_sock_destruct_work+0x1c/0x20
|
|
process_one_work+0x411/0x710
|
|
worker_thread+0x6fd/0xa80</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2021-47612</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
|
|
|
|
kobject_init_and_add() takes reference even when it fails.
|
|
According to the doc of kobject_init_and_add()?
|
|
|
|
If this function returns an error, kobject_put() must be called to
|
|
properly clean up the memory associated with the object.
|
|
|
|
Fix memory leak by calling kobject_put().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48775</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-rdma: fix possible use-after-free in transport error_recovery work
|
|
|
|
While nvme_rdma_submit_async_event_work is checking the ctrl and queue
|
|
state before preparing the AER command and scheduling io_work, in order
|
|
to fully prevent a race where this check is not reliable the error
|
|
recovery work must flush async_event_work before continuing to destroy
|
|
the admin queue after setting the ctrl state to RESETTING such that
|
|
there is no race .submit_async_event and the error recovery handler
|
|
itself changing the ctrl state.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48788</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
|
|
|
|
The syzbot fuzzer found a use-after-free bug:
|
|
|
|
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
|
|
Read of size 8 at addr ffff88802b934098 by task udevd/3689
|
|
|
|
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
|
|
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
|
|
__kasan_report mm/kasan/report.c:442 [inline]
|
|
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
|
|
dev_uevent+0x712/0x780 drivers/base/core.c:2320
|
|
uevent_show+0x1b8/0x380 drivers/base/core.c:2391
|
|
dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
|
|
|
|
Although the bug manifested in the driver core, the real cause was a
|
|
race with the gadget core. dev_uevent() does:
|
|
|
|
if (dev->driver)
|
|
add_uevent_var(env, "DRIVER=%s", dev->driver->name);
|
|
|
|
and between the test and the dereference of dev->driver, the gadget
|
|
core sets dev->driver to NULL.
|
|
|
|
The race wouldn't occur if the gadget core registered its devices on
|
|
a real bus, using the standard synchronization techniques of the
|
|
driver core. However, it's not necessary to make such a large change
|
|
in order to fix this bug; all we need to do is make sure that
|
|
udc->dev.driver is always NULL.
|
|
|
|
In fact, there is no reason for udc->dev.driver ever to be set to
|
|
anything, let alone to the value it currently gets: the address of the
|
|
gadget's driver. After all, a gadget driver only knows how to manage
|
|
a gadget, not how to manage a UDC.
|
|
|
|
This patch simply removes the statements in the gadget core that touch
|
|
udc->dev.driver.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48838</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sctp: fix kernel-infoleak for SCTP sockets
|
|
|
|
syzbot reported a kernel infoleak [1] of 4 bytes.
|
|
|
|
After analysis, it turned out r->idiag_expires is not initialized
|
|
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
|
|
|
|
Make sure to clear idiag_timer/idiag_retrans/idiag_expires
|
|
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
|
|
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
copyout lib/iov_iter.c:154 [inline]
|
|
_copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
|
|
copy_to_iter include/linux/uio.h:162 [inline]
|
|
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
|
|
__skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
|
|
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
|
|
netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
|
|
sock_recvmsg_nosec net/socket.c:948 [inline]
|
|
sock_recvmsg net/socket.c:966 [inline]
|
|
__sys_recvfrom+0x795/0xa10 net/socket.c:2097
|
|
__do_sys_recvfrom net/socket.c:2115 [inline]
|
|
__se_sys_recvfrom net/socket.c:2111 [inline]
|
|
__x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slab.h:737 [inline]
|
|
slab_alloc_node mm/slub.c:3247 [inline]
|
|
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
|
|
kmalloc_reserve net/core/skbuff.c:354 [inline]
|
|
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
|
|
alloc_skb include/linux/skbuff.h:1158 [inline]
|
|
netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
|
|
__netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
|
|
netlink_dump_start include/linux/netlink.h:254 [inline]
|
|
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
|
|
sock_diag_rcv_msg+0x24a/0x620
|
|
netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
|
|
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
|
|
netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
|
|
netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
|
|
sock_sendmsg_nosec net/socket.c:705 [inline]
|
|
sock_sendmsg net/socket.c:725 [inline]
|
|
sock_write_iter+0x594/0x690 net/socket.c:1061
|
|
do_iter_readv_writev+0xa7f/0xc70
|
|
do_iter_write+0x52c/0x1500 fs/read_write.c:851
|
|
vfs_writev fs/read_write.c:924 [inline]
|
|
do_writev+0x645/0xe00 fs/read_write.c:967
|
|
__do_sys_writev fs/read_write.c:1040 [inline]
|
|
__se_sys_writev fs/read_write.c:1037 [inline]
|
|
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Bytes 68-71 of 2508 are uninitialized
|
|
Memory access of size 2508 starts at ffff888114f9b000
|
|
Data copied to user address 00007f7fe09ff2e0
|
|
|
|
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48855</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:gianfar: ethtool: Fix refcount leak in gfar_get_ts_infoThe of_find_compatible_node() function returns a node pointer withrefcount incremented, We should use of_node_put() on it when doneAdd the missing of_node_put() to release the refcount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48856</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:tipc: fix kernel panic when enabling bearerWhen enabling a bearer on a node, a kernel panic is observed:[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]...[ 4.520030] Call Trace:[ 4.520689] <IRQ>[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc][ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc][ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc][ 4.525292] tipc_rcv+0x5da/0x730 [tipc][ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc][ 4.528737] __netif_receive_skb_list_core+0x20b/0x260[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0[ 4.531450] ? dev_gro_receive+0x4c2/0x680[ 4.532512] napi_complete_done+0x6f/0x180[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]...The node in question is receiving activate messages in anotherthread after changing bearer status to allow message sending/receiving in current thread: thread 1 | thread 2 -------- | -------- |tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |Monitoring pointer in thread 2 is dereferenced before monitoring datais allocated in thread 1. This causes kernel panic.This commit fixes it by allocating the monitoring data before enablingthe bearer to receive messages.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48865</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: fix possible dead-lock in nr_rt_ioctl()
|
|
|
|
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
|
|
|
|
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
|
|
|
|
[1]
|
|
WARNING: possible circular locking dependency detected
|
|
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
|
|
------------------------------------------------------
|
|
syz-executor350/5129 is trying to acquire lock:
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
|
|
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
|
|
|
|
but task is already holding lock:
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
|
|
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
|
|
|
|
which lock already depends on the new lock.
|
|
|
|
the existing dependency chain (in reverse order) is:
|
|
|
|
-> #1 (nr_node_list_lock){+...}-{2:2}:
|
|
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
|
|
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
|
|
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
|
|
spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
nr_remove_node net/netrom/nr_route.c:299 [inline]
|
|
nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
|
|
nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
|
|
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
|
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
-> #0 (&nr_node->node_lock){+...}-{2:2}:
|
|
check_prev_add kernel/locking/lockdep.c:3134 [inline]
|
|
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
|
|
validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
|
|
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
|
|
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
|
|
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
|
|
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
|
|
spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
nr_node_lock include/net/netrom.h:152 [inline]
|
|
nr_dec_obs net/netrom/nr_route.c:464 [inline]
|
|
nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
|
|
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
|
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
other info that might help us debug this:
|
|
|
|
Possible unsafe locking scenario:
|
|
|
|
CPU0 CPU1
|
|
---- ----
|
|
lock(nr_node_list_lock);
|
|
lock(&nr_node->node_lock);
|
|
lock(nr_node_list_lock);
|
|
lock(&nr_node->node_lock);
|
|
|
|
*** DEADLOCK ***
|
|
|
|
1 lock held by syz-executor350/5129:
|
|
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
|
|
#0: ffffffff8f70
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38589</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
|
|
|
|
Using completion_done to determine whether the caller has gone
|
|
away only works after a complete call. Furthermore it's still
|
|
possible that the caller has not yet called wait_for_completion,
|
|
resulting in another potential UAF.
|
|
|
|
Fix this by making the caller use cancel_work_sync and then freeing
|
|
the memory safely.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39493</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ima: Fix use-after-free on a dentry's dname.name
|
|
|
|
->d_name.name can change on rename and the earlier value can be freed;
|
|
there are conditions sufficient to stabilize it (->d_lock on dentry,
|
|
->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,
|
|
rename_lock), but none of those are met at any of the sites. Take a stable
|
|
snapshot of the name instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39494</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vmci: prevent speculation leaks by sanitizing event in event_deliver()
|
|
|
|
Coverity spotted that event_msg is controlled by user-space,
|
|
event_msg->event_data.event is passed to event_deliver() and used
|
|
as an index without sanitization.
|
|
|
|
This change ensures that the event index is sanitized to mitigate any
|
|
possibility of speculative information leaks.
|
|
|
|
This bug was discovered and resolved using Coverity Static Analysis
|
|
Security Testing (SAST) by Synopsys, Inc.
|
|
|
|
Only compile tested, no access to HW.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39499</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
|
|
|
|
The syzbot fuzzer found that the interrupt-URB completion callback in
|
|
the cdc-wdm driver was taking too long, and the driver's immediate
|
|
resubmission of interrupt URBs with -EPROTO status combined with the
|
|
dummy-hcd emulation to cause a CPU lockup:
|
|
|
|
cdc_wdm 1-1:1.0: nonzero urb status received: -71
|
|
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
|
|
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
|
|
CPU#0 Utilization every 4s during lockup:
|
|
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
|
|
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
|
|
Modules linked in:
|
|
irq event stamp: 73096
|
|
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
|
|
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
|
|
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
|
|
softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
|
|
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
|
|
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
|
|
Testing showed that the problem did not occur if the two error
|
|
messages -- the first two lines above -- were removed; apparently adding
|
|
material to the kernel log takes a surprisingly large amount of time.
|
|
|
|
In any case, the best approach for preventing these lockups and to
|
|
avoid spamming the log with thousands of error messages per second is
|
|
to ratelimit the two dev_err() calls. Therefore we replace them with
|
|
dev_err_ratelimited().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40904</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
|
|
|
|
The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to
|
|
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
|
|
softirq context. However using only spin_lock() to get sta->ps_lock in
|
|
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
|
|
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
|
|
take this same lock ending in deadlock. Below is an example of rcu stall
|
|
that arises in such situation.
|
|
|
|
rcu: INFO: rcu_sched self-detected stall on CPU
|
|
rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
|
|
rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)
|
|
CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742
|
|
Hardware name: RPT (r1) (DT)
|
|
pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : queued_spin_lock_slowpath+0x58/0x2d0
|
|
lr : invoke_tx_handlers_early+0x5b4/0x5c0
|
|
sp : ffff00001ef64660
|
|
x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
|
|
x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
|
|
x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
|
|
x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
|
|
x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
|
|
x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
|
|
x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
|
|
x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
|
|
x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
|
|
Call trace:
|
|
queued_spin_lock_slowpath+0x58/0x2d0
|
|
ieee80211_tx+0x80/0x12c
|
|
ieee80211_tx_pending+0x110/0x278
|
|
tasklet_action_common.constprop.0+0x10c/0x144
|
|
tasklet_action+0x20/0x28
|
|
_stext+0x11c/0x284
|
|
____do_softirq+0xc/0x14
|
|
call_on_irq_stack+0x24/0x34
|
|
do_softirq_own_stack+0x18/0x20
|
|
do_softirq+0x74/0x7c
|
|
__local_bh_enable_ip+0xa0/0xa4
|
|
_ieee80211_wake_txqs+0x3b0/0x4b8
|
|
__ieee80211_wake_queue+0x12c/0x168
|
|
ieee80211_add_pending_skbs+0xec/0x138
|
|
ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
|
|
ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
|
|
ieee80211_mps_sta_status_update+0x18/0x24
|
|
sta_apply_parameters+0x3bc/0x4c0
|
|
ieee80211_change_station+0x1b8/0x2dc
|
|
nl80211_set_station+0x444/0x49c
|
|
genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
|
|
genl_rcv_msg+0x1b0/0x244
|
|
netlink_rcv_skb+0x38/0x10c
|
|
genl_rcv+0x34/0x48
|
|
netlink_unicast+0x254/0x2bc
|
|
netlink_sendmsg+0x190/0x3b4
|
|
____sys_sendmsg+0x1e8/0x218
|
|
___sys_sendmsg+0x68/0x8c
|
|
__sys_sendmsg+0x44/0x84
|
|
__arm64_sys_sendmsg+0x20/0x28
|
|
do_el0_svc+0x6c/0xe8
|
|
el0_svc+0x14/0x48
|
|
el0t_64_sync_handler+0xb0/0xb4
|
|
el0t_64_sync+0x14c/0x150
|
|
|
|
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
|
|
on the same CPU that is holding the lock.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40912</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
|
|
|
|
In some versions of cfg80211, the ssids poinet might be a valid one even
|
|
though n_ssids is 0. Accessing the pointer in this case will cuase an
|
|
out-of-bound access. Fix this by checking n_ssids first.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40929</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/exynos/vidi: fix memory leak in .get_modes()
|
|
|
|
The duplicated EDID is never freed. Fix it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40932</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: mvm: don't read past the mfuart notifcation
|
|
|
|
In case the firmware sends a notification that claims it has more data
|
|
than it has, we will read past that was allocated for the notification.
|
|
Remove the print of the buffer, we won't see it by default. If needed,
|
|
we can see the content with tracing.
|
|
|
|
This was reported by KFENCE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40941</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix races between hole punching and AIO+DIO
|
|
|
|
After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
|
|
fstests/generic/300 become from always failed to sometimes failed:
|
|
|
|
========================================================================
|
|
[ 473.293420 ] run fstests generic/300
|
|
|
|
[ 475.296983 ] JBD2: Ignoring recovery information on journal
|
|
[ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
|
|
[ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
|
|
[ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
|
|
[ 494.292018 ] OCFS2: File system is now read-only.
|
|
[ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
|
|
[ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
|
|
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
|
|
=========================================================================
|
|
|
|
In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
|
|
extents to a list. extents are also inserted into extent tree in
|
|
ocfs2_write_begin_nolock. Then another thread call fallocate to puch a
|
|
hole at one of the unwritten extent. The extent at cpos was removed by
|
|
ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list
|
|
found there is no such extent at the cpos.
|
|
|
|
T1 T2 T3
|
|
inode lock
|
|
...
|
|
insert extents
|
|
...
|
|
inode unlock
|
|
ocfs2_fallocate
|
|
__ocfs2_change_file_space
|
|
inode lock
|
|
lock ip_alloc_sem
|
|
ocfs2_remove_inode_range inode
|
|
ocfs2_remove_btree_range
|
|
ocfs2_remove_extent
|
|
^---remove the extent at cpos 78723
|
|
...
|
|
unlock ip_alloc_sem
|
|
inode unlock
|
|
ocfs2_dio_end_io
|
|
ocfs2_dio_end_io_write
|
|
lock ip_alloc_sem
|
|
ocfs2_mark_extent_written
|
|
ocfs2_change_extent_flag
|
|
ocfs2_search_extent_list
|
|
^---failed to find extent
|
|
...
|
|
unlock ip_alloc_sem
|
|
|
|
In most filesystems, fallocate is not compatible with racing with AIO+DIO,
|
|
so fix it by adding to wait for all dio before fallocate/punch_hole like
|
|
ext4.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40943</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
MIPS: Octeon: Add PCIe link status check
|
|
|
|
The standard PCIe configuration read-write interface is used to
|
|
access the configuration space of the peripheral PCIe devices
|
|
of the mips processor after the PCIe link surprise down, it can
|
|
generate kernel panic caused by "Data bus error". So it is
|
|
necessary to add PCIe link status check for system protection.
|
|
When the PCIe link is down or in training, assigning a value
|
|
of 0 to the configuration address can prevent read-write behavior
|
|
to the configuration space of peripheral PCIe devices, thereby
|
|
preventing kernel panic.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40968</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/pseries: Enforce hcall result buffer validity and size
|
|
|
|
plpar_hcall(), plpar_hcall9(), and related functions expect callers to
|
|
provide valid result buffers of certain minimum size. Currently this
|
|
is communicated only through comments in the code and the compiler has
|
|
no idea.
|
|
|
|
For example, if I write a bug like this:
|
|
|
|
long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
|
|
plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);
|
|
|
|
This compiles with no diagnostics emitted, but likely results in stack
|
|
corruption at runtime when plpar_hcall9() stores results past the end
|
|
of the array. (To be clear this is a contrived example and I have not
|
|
found a real instance yet.)
|
|
|
|
To make this class of error less likely, we can use explicitly-sized
|
|
array parameters instead of pointers in the declarations for the hcall
|
|
APIs. When compiled with -Warray-bounds[1], the code above now
|
|
provokes a diagnostic like this:
|
|
|
|
error: array argument is too small;
|
|
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
|
|
60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
|
|
| ^ ~~~~~~
|
|
|
|
[1] Enabled for LLVM builds but not GCC for now. See commit
|
|
0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
|
|
related changes.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40974</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
|
|
|
|
Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
|
|
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
|
|
purpose of this commit was to stop memory mappings for operation
|
|
regions from overlapping page boundaries, as it can trigger warnings
|
|
if different page attributes are present.
|
|
|
|
However, it was found that when this situation arises, mapping
|
|
continues until the boundary's end, but there is still an attempt to
|
|
read/write the entire length of the map, leading to a NULL pointer
|
|
deference. For example, if a four-byte mapping request is made but
|
|
only one byte is mapped because it hits the current page boundary's
|
|
end, a four-byte read/write attempt is still made, resulting in a NULL
|
|
pointer deference.
|
|
|
|
Instead, map the entire length, as the ACPI specification does not
|
|
mandate that it must be within the same page boundary. It is
|
|
permissible for it to be mapped across different regions.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40984</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: fix UBSAN warning in kv_dpm.c
|
|
|
|
Adds bounds check for sumo_vid_mapping_entry.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40987</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netpoll: Fix race condition in netpoll_owner_active
|
|
|
|
KCSAN detected a race condition in netpoll:
|
|
|
|
BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
|
|
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
|
|
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
|
|
<snip>
|
|
read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
|
|
netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
|
|
netpoll_send_udp (net/core/netpoll.c:?)
|
|
<snip>
|
|
value changed: 0x0000000a -> 0xffffffff
|
|
|
|
This happens because netpoll_owner_active() needs to check if the
|
|
current CPU is the owner of the lock, touching napi->poll_owner
|
|
non atomically. The ->poll_owner field contains the current CPU holding
|
|
the lock.
|
|
|
|
Use an atomic read to check if the poll owner is the current CPU.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-41005</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: avoid too many retransmit packets
|
|
|
|
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
|
|
retracted its window to zero, tcp_retransmit_timer() can
|
|
retransmit a packet every two jiffies (2 ms for HZ=1000),
|
|
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
|
|
|
|
The fix is to make sure tcp_rtx_probe0_timed_out() takes
|
|
icsk->icsk_user_timeout into account.
|
|
|
|
Before blamed commit, the socket would not timeout after
|
|
icsk->icsk_user_timeout, but would use standard exponential
|
|
backoff for the retransmits.
|
|
|
|
Also worth noting that before commit e89688e3e978 ("net: tcp:
|
|
fix unexcepted socket die when snd_wnd is 0"), the issue
|
|
would last 2 minutes instead of 4.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-41007</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |