3106 lines
138 KiB
XML
3106 lines
138 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1896</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-22.03-LTS-SP1</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
lib/generic-radix-tree.c: Don't overflow in peek()
|
|
|
|
When we started spreading new inode numbers throughout most of the 64
|
|
bit inode space, that triggered some corner case bugs, in particular
|
|
some integer overflows related to the radix tree code. Oops.(CVE-2021-47432)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: ufs: Fix a deadlock in the error handler
|
|
|
|
The following deadlock has been observed on a test setup:
|
|
|
|
- All tags allocated
|
|
|
|
- The SCSI error handler calls ufshcd_eh_host_reset_handler()
|
|
|
|
- ufshcd_eh_host_reset_handler() queues work that calls
|
|
ufshcd_err_handler()
|
|
|
|
- ufshcd_err_handler() locks up as follows:
|
|
|
|
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
|
|
Call trace:
|
|
__switch_to+0x298/0x5d8
|
|
__schedule+0x6cc/0xa94
|
|
schedule+0x12c/0x298
|
|
blk_mq_get_tag+0x210/0x480
|
|
__blk_mq_alloc_request+0x1c8/0x284
|
|
blk_get_request+0x74/0x134
|
|
ufshcd_exec_dev_cmd+0x68/0x640
|
|
ufshcd_verify_dev_init+0x68/0x35c
|
|
ufshcd_probe_hba+0x12c/0x1cb8
|
|
ufshcd_host_reset_and_restore+0x88/0x254
|
|
ufshcd_reset_and_restore+0xd0/0x354
|
|
ufshcd_err_handler+0x408/0xc58
|
|
process_one_work+0x24c/0x66c
|
|
worker_thread+0x3e8/0xa4c
|
|
kthread+0x150/0x1b4
|
|
ret_from_fork+0x10/0x30
|
|
|
|
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
|
|
request.(CVE-2021-47622)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: dsa: seville: register the mdiobus under devres
|
|
|
|
As explained in commits:
|
|
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
|
|
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
|
|
|
|
mdiobus_free() will panic when called from devm_mdiobus_free() <-
|
|
devres_release_all() <- __device_release_driver(), and that mdiobus was
|
|
not previously unregistered.
|
|
|
|
The Seville VSC9959 switch is a platform device, so the initial set of
|
|
constraints that I thought would cause this (I2C or SPI buses which call
|
|
->remove on ->shutdown) do not apply. But there is one more which
|
|
applies here.
|
|
|
|
If the DSA master itself is on a bus that calls ->remove from ->shutdown
|
|
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
|
|
between the switch and the DSA master, and device_links_unbind_consumers()
|
|
will unbind the seville switch driver on shutdown.
|
|
|
|
So the same treatment must be applied to all DSA switch drivers, which
|
|
is: either use devres for both the mdiobus allocation and registration,
|
|
or don't use devres at all.
|
|
|
|
The seville driver has a code structure that could accommodate both the
|
|
mdiobus_unregister and mdiobus_free calls, but it has an external
|
|
dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls
|
|
devm_mdiobus_alloc_size() on its behalf. So rather than restructuring
|
|
that, and exporting yet one more symbol mscc_miim_teardown(), let's work
|
|
with devres and replace of_mdiobus_register with the devres variant.
|
|
When we use all-devres, we can ensure that devres doesn't free a
|
|
still-registered bus (it either runs both callbacks, or none).(CVE-2022-48814)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: lock against ->sock changing during sysfs read
|
|
|
|
->sock can be set to NULL asynchronously unless ->recv_mutex is held.
|
|
So it is important to hold that mutex. Otherwise a sysfs read can
|
|
trigger an oops.
|
|
Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before
|
|
handling sysfs reads") appears to attempt to fix this problem, but it
|
|
only narrows the race window.(CVE-2022-48816)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: hci_core: Fix leaking sent_cmd skb
|
|
|
|
sent_cmd memory is not freed before freeing hci_dev causing it to leak
|
|
it contents.(CVE-2022-48844)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
smb: client: fix potential deadlock when releasing mids
|
|
|
|
All release_mid() callers seem to hold a reference of @mid so there is
|
|
no need to call kref_put(&mid->refcount, __release_mid) under
|
|
@server->mid_lock spinlock. If they don't, then an use-after-free bug
|
|
would have occurred anyways.
|
|
|
|
By getting rid of such spinlock also fixes a potential deadlock as
|
|
shown below
|
|
|
|
CPU 0 CPU 1
|
|
------------------------------------------------------------------
|
|
cifs_demultiplex_thread() cifs_debug_data_proc_show()
|
|
release_mid()
|
|
spin_lock(&server->mid_lock);
|
|
spin_lock(&cifs_tcp_ses_lock)
|
|
spin_lock(&server->mid_lock)
|
|
__release_mid()
|
|
smb2_find_smb_tcon()
|
|
spin_lock(&cifs_tcp_ses_lock) *deadlock*(CVE-2023-52757)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
|
|
|
|
The BOS descriptor defines a root descriptor and is the base descriptor for
|
|
accessing a family of related descriptors.
|
|
|
|
Function 'usb_get_bos_descriptor()' encounters an iteration issue when
|
|
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
|
|
the same descriptor being read repeatedly.
|
|
|
|
To address this issue, a 'goto' statement is introduced to ensure that the
|
|
pointer and the amount read is updated correctly. This ensures that the
|
|
function iterates to the next descriptor instead of reading the same
|
|
descriptor repeatedly.(CVE-2023-52781)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfs: Handle error of rpc_proc_register() in nfs_net_init().
|
|
|
|
syzkaller reported a warning [0] triggered while destroying immature
|
|
netns.
|
|
|
|
rpc_proc_register() was called in init_nfs_fs(), but its error
|
|
has been ignored since at least the initial commit 1da177e4c3f4
|
|
("Linux-2.6.12-rc2").
|
|
|
|
Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
|
|
in net namespaces") converted the procfs to per-netns and made
|
|
the problem more visible.
|
|
|
|
Even when rpc_proc_register() fails, nfs_net_init() could succeed,
|
|
and thus nfs_net_exit() will be called while destroying the netns.
|
|
|
|
Then, remove_proc_entry() will be called for non-existing proc
|
|
directory and trigger the warning below.
|
|
|
|
Let's handle the error of rpc_proc_register() properly in nfs_net_init().
|
|
|
|
[0]:
|
|
name 'nfs'
|
|
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
|
|
Modules linked in:
|
|
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
|
|
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
|
|
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
|
|
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
|
|
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
|
|
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
|
|
FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
|
|
nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
|
|
ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
|
|
setup_net+0x46c/0x660 net/core/net_namespace.c:372
|
|
copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
|
|
create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
|
|
unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
|
|
ksys_unshare+0x342/0x760 kernel/fork.c:3322
|
|
__do_sys_unshare kernel/fork.c:3393 [inline]
|
|
__se_sys_unshare kernel/fork.c:3391 [inline]
|
|
__x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0x7f30d0febe5d
|
|
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
|
|
RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
|
|
RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
|
|
R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
|
|
</TASK>(CVE-2024-36939)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: qedf: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a count-sized kernel buffer and copy count from
|
|
userspace to that buffer. Later, we use kstrtouint on this buffer but we
|
|
don't ensure that the string is terminated inside the buffer, this can
|
|
lead to OOB read when using kstrtouint. Fix this issue by using
|
|
memdup_user_nul instead of memdup_user.(CVE-2024-38559)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group
|
|
|
|
The perf tool allows users to create event groups through following
|
|
cmd [1], but the driver does not check whether the array index is out
|
|
of bounds when writing data to the event_group array. If the number of
|
|
events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the
|
|
memory write overflow of event_group array occurs.
|
|
|
|
Add array index check to fix the possible array out of bounds violation,
|
|
and return directly when write new events are written to array bounds.
|
|
|
|
There are 9 different events in an event_group.
|
|
[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}(CVE-2024-38568)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ecryptfs: Fix buffer size for tag 66 packet
|
|
|
|
The 'TAG 66 Packet Format' description is missing the cipher code and
|
|
checksum fields that are packed into the message packet. As a result,
|
|
the buffer allocated for the packet is 3 bytes too small and
|
|
write_tag_66_packet() will write up to 3 bytes past the end of the
|
|
buffer.
|
|
|
|
Fix this by increasing the size of the allocation so the whole packet
|
|
will always fit in the buffer.
|
|
|
|
This fixes the below kasan slab-out-of-bounds bug:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
|
|
|
|
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x4c/0x70
|
|
print_report+0xc5/0x610
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? kasan_complete_mode_report_info+0x44/0x210
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
kasan_report+0xc2/0x110
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
__asan_store1+0x62/0x80
|
|
ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
|
|
? __alloc_pages+0x2e2/0x540
|
|
? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
|
|
? dentry_open+0x8f/0xd0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
? __pfx_ecryptfs_write_metadata+0x10/0x10
|
|
? ecryptfs_get_lower_file+0x6b/0x190
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
? __pfx_path_openat+0x10/0x10
|
|
do_filp_open+0x15e/0x290
|
|
? __pfx_do_filp_open+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? _raw_spin_lock+0x86/0xf0
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? alloc_fd+0xf4/0x330
|
|
do_sys_openat2+0x122/0x160
|
|
? __pfx_do_sys_openat2+0x10/0x10
|
|
__x64_sys_openat+0xef/0x170
|
|
? __pfx___x64_sys_openat+0x10/0x10
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
RIP: 0033:0x7f00a703fd67
|
|
Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
|
|
RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
|
|
RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
|
|
RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
|
|
RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
|
|
R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
|
|
</TASK>
|
|
|
|
Allocated by task 181:
|
|
kasan_save_stack+0x2f/0x60
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x25/0x40
|
|
__kasan_kmalloc+0xc5/0xd0
|
|
__kmalloc+0x66/0x160
|
|
ecryptfs_generate_key_packet_set+0x6d2/0xde0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
do_filp_open+0x15e/0x290
|
|
do_sys_openat2+0x122/0x160
|
|
__x64_sys_openat+0xef/0x170
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2024-38578)
|
|
|
|
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:
|
|
|
|
ALSA: timer: Set lower bound of start tick time
|
|
|
|
Currently ALSA timer doesn't have the lower limit of the start tick
|
|
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
|
|
for hrtimer. Such a situation may lead to an unexpected RCU stall,
|
|
where the callback repeatedly queuing the expire update, as reported
|
|
by fuzzer.
|
|
|
|
This patch introduces a sanity check of the timer start tick time, so
|
|
that the system returns an error when a too small start size is set.
|
|
As of this patch, the lower limit is hard-coded to 100us, which is
|
|
small enough but can still work somehow.(CVE-2024-38618)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb-storage: alauda: Check whether the media is initialized
|
|
|
|
The member "uzonesize" of struct alauda_info will remain 0
|
|
if alauda_init_media() fails, potentially causing divide errors
|
|
in alauda_read_data() and alauda_write_lba().
|
|
- Add a member "media_initialized" to struct alauda_info.
|
|
- Change a condition in alauda_check_media() to ensure the
|
|
first initialization.
|
|
- Add an error check for the return value of alauda_init_media().(CVE-2024-38619)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
|
|
|
|
The error handling in nilfs_empty_dir() when a directory folio/page read
|
|
fails is incorrect, as in the old ext2 implementation, and if the
|
|
folio/page cannot be read or nilfs_check_folio() fails, it will falsely
|
|
determine the directory as empty and corrupt the file system.
|
|
|
|
In addition, since nilfs_empty_dir() does not immediately return on a
|
|
failed folio/page read, but continues to loop, this can cause a long loop
|
|
with I/O if i_size of the directory's inode is also corrupted, causing the
|
|
log writer thread to wait and hang, as reported by syzbot.
|
|
|
|
Fix these issues by making nilfs_empty_dir() immediately return a false
|
|
value (0) if it fails to get a directory folio/page.(CVE-2024-39469)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xfs: fix log recovery buffer allocation for the legacy h_size fixup
|
|
|
|
Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by
|
|
mkfs") added a fixup for incorrect h_size values used for the initial
|
|
umount record in old xfsprogs versions. Later commit 0c771b99d6c9
|
|
("xfs: clean up calculation of LR header blocks") cleaned up the log
|
|
reover buffer calculation, but stoped using the fixed up h_size value
|
|
to size the log recovery buffer, which can lead to an out of bounds
|
|
access when the incorrect h_size does not come from the old mkfs
|
|
tool, but a fuzzer.
|
|
|
|
Fix this by open coding xlog_logrec_hblks and taking the fixed h_size
|
|
into account for this calculation.(CVE-2024-39472)
|
|
|
|
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:
|
|
|
|
drm/komeda: check for error-valued pointer
|
|
|
|
komeda_pipeline_get_state() may return an error-valued pointer, thus
|
|
check the pointer for negative or null value before dereferencing.(CVE-2024-39505)
|
|
|
|
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:
|
|
|
|
ipv6: fix possible race in __fib6_drop_pcpu_from()
|
|
|
|
syzbot found a race in __fib6_drop_pcpu_from() [1]
|
|
|
|
If compiler reads more than once (*ppcpu_rt),
|
|
second read could read NULL, if another cpu clears
|
|
the value in rt6_get_pcpu_route().
|
|
|
|
Add a READ_ONCE() to prevent this race.
|
|
|
|
Also add rcu_read_lock()/rcu_read_unlock() because
|
|
we rely on RCU protection while dereferencing pcpu_rt.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
|
|
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
Workqueue: netns cleanup_net
|
|
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
|
|
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
|
|
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
|
|
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
|
|
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
|
|
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
|
|
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
|
|
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
|
|
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
__fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
|
|
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
|
|
fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
|
|
fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
|
|
fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
|
|
fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
|
|
fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
|
|
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
|
|
fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
|
|
__fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
|
|
rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
|
|
rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
|
|
addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
|
|
addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
|
|
notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
|
|
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
|
|
call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
|
|
call_netdevice_notifiers net/core/dev.c:2044 [inline]
|
|
dev_close_many+0x333/0x6a0 net/core/dev.c:1585
|
|
unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
|
|
unregister_netdevice_many net/core/dev.c:11276 [inline]
|
|
default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
|
|
ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
|
|
cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
|
|
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
|
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
|
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
|
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40905)
|
|
|
|
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:
|
|
|
|
tipc: force a dst refcount before doing decryption
|
|
|
|
As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before
|
|
entering the xfrm type handlers"):
|
|
|
|
"Crypto requests might return asynchronous. In this case we leave the
|
|
rcu protected region, so force a refcount on the skb's destination
|
|
entry before we enter the xfrm type input/output handlers."
|
|
|
|
On TIPC decryption path it has the same problem, and skb_dst_force()
|
|
should be called before doing decryption to avoid a possible crash.
|
|
|
|
Shuang reported this issue when this warning is triggered:
|
|
|
|
[] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
|
|
[] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
|
|
[] Workqueue: crypto cryptd_queue_worker
|
|
[] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
|
|
[] Call Trace:
|
|
[] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
|
|
[] tipc_rcv+0xcf5/0x1060 [tipc]
|
|
[] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
|
|
[] cryptd_aead_crypt+0xdb/0x190
|
|
[] cryptd_queue_worker+0xed/0x190
|
|
[] process_one_work+0x93d/0x17e0(CVE-2024-40983)
|
|
|
|
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:
|
|
|
|
tracing: Build event generation tests only as modules
|
|
|
|
The kprobes and synth event generation test modules add events and lock
|
|
(get a reference) those event file reference in module init function,
|
|
and unlock and delete it in module exit function. This is because those
|
|
are designed for playing as modules.
|
|
|
|
If we make those modules as built-in, those events are left locked in the
|
|
kernel, and never be removed. This causes kprobe event self-test failure
|
|
as below.
|
|
|
|
[ 97.349708] ------------[ cut here ]------------
|
|
[ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.357106] Modules linked in:
|
|
[ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14
|
|
[ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
[ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90
|
|
[ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286
|
|
[ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000
|
|
[ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68
|
|
[ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
[ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000
|
|
[ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000
|
|
[ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
|
|
[ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0
|
|
[ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 97.391196] Call Trace:
|
|
[ 97.391967] <TASK>
|
|
[ 97.392647] ? __warn+0xcc/0x180
|
|
[ 97.393640] ? kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.395181] ? report_bug+0xbd/0x150
|
|
[ 97.396234] ? handle_bug+0x3e/0x60
|
|
[ 97.397311] ? exc_invalid_op+0x1a/0x50
|
|
[ 97.398434] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 97.399652] ? trace_kprobe_is_busy+0x20/0x20
|
|
[ 97.400904] ? tracing_reset_all_online_cpus+0x15/0x90
|
|
[ 97.402304] ? kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.403773] ? init_kprobe_trace+0x50/0x50
|
|
[ 97.404972] do_one_initcall+0x112/0x240
|
|
[ 97.406113] do_initcall_level+0x95/0xb0
|
|
[ 97.407286] ? kernel_init+0x1a/0x1a0
|
|
[ 97.408401] do_initcalls+0x3f/0x70
|
|
[ 97.409452] kernel_init_freeable+0x16f/0x1e0
|
|
[ 97.410662] ? rest_init+0x1f0/0x1f0
|
|
[ 97.411738] kernel_init+0x1a/0x1a0
|
|
[ 97.412788] ret_from_fork+0x39/0x50
|
|
[ 97.413817] ? rest_init+0x1f0/0x1f0
|
|
[ 97.414844] ret_from_fork_asm+0x11/0x20
|
|
[ 97.416285] </TASK>
|
|
[ 97.417134] irq event stamp: 13437323
|
|
[ 97.418376] hardirqs last enabled at (13437337): [<ffffffff8110bc0c>] console_unlock+0x11c/0x150
|
|
[ 97.421285] hardirqs last disabled at (13437370): [<ffffffff8110bbf1>] console_unlock+0x101/0x150
|
|
[ 97.423838] softirqs last enabled at (13437366): [<ffffffff8108e17f>] handle_softirqs+0x23f/0x2a0
|
|
[ 97.426450] softirqs last disabled at (13437393): [<ffffffff8108e346>] __irq_exit_rcu+0x66/0xd0
|
|
[ 97.428850] ---[ end trace 0000000000000000 ]---
|
|
|
|
And also, since we can not cleanup dynamic_event file, ftracetest are
|
|
failed too.
|
|
|
|
To avoid these issues, build these tests only as modules.(CVE-2024-41004)
|
|
|
|
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)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Fix overrunning reservations in ringbuf
|
|
|
|
The BPF ring buffer internally is implemented as a power-of-2 sized circular
|
|
buffer, with two logical and ever-increasing counters: consumer_pos is the
|
|
consumer counter to show which logical position the consumer consumed the
|
|
data, and producer_pos which is the producer counter denoting the amount of
|
|
data reserved by all producers.
|
|
|
|
Each time a record is reserved, the producer that "owns" the record will
|
|
successfully advance producer counter. In user space each time a record is
|
|
read, the consumer of the data advanced the consumer counter once it finished
|
|
processing. Both counters are stored in separate pages so that from user
|
|
space, the producer counter is read-only and the consumer counter is read-write.
|
|
|
|
One aspect that simplifies and thus speeds up the implementation of both
|
|
producers and consumers is how the data area is mapped twice contiguously
|
|
back-to-back in the virtual memory, allowing to not take any special measures
|
|
for samples that have to wrap around at the end of the circular buffer data
|
|
area, because the next page after the last data page would be first data page
|
|
again, and thus the sample will still appear completely contiguous in virtual
|
|
memory.
|
|
|
|
Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
|
|
book-keeping the length and offset, and is inaccessible to the BPF program.
|
|
Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
|
|
for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
|
|
possible to make a second allocated memory chunk overlapping with the first
|
|
chunk and as a result, the BPF program is now able to edit first chunk's
|
|
header.
|
|
|
|
For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
|
|
of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
|
|
bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
|
|
[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
|
|
allocate a chunk B with size 0x3000. This will succeed because consumer_pos
|
|
was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`
|
|
check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
|
|
to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
|
|
earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
|
|
pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
|
|
bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
|
|
locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
|
|
B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
|
|
page and could cause a crash.
|
|
|
|
Fix it by calculating the oldest pending_pos and check whether the range
|
|
from the oldest outstanding record to the newest would span beyond the ring
|
|
buffer size. If that is the case, then reject the request. We've tested with
|
|
the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
|
|
before/after the fix and while it seems a bit slower on some benchmarks, it
|
|
is still not significantly enough to matter.(CVE-2024-41009)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47432</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47622</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48814</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48816</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48844</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52757</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52781</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36939</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38559</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38568</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38578</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-38618</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38619</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39469</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39472</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-39505</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-40905</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-40983</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-41004</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>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41009</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47432</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47622</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48814</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48816</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48844</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52757</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52781</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36939</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38559</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38568</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38578</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38589</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38619</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39469</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39472</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-39505</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40904</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40905</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-40983</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-41004</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41005</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41007</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41009</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.86.0.167.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.86.0.167" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
lib/generic-radix-tree.c: Don't overflow in peek()
|
|
|
|
When we started spreading new inode numbers throughout most of the 64
|
|
bit inode space, that triggered some corner case bugs, in particular
|
|
some integer overflows related to the radix tree code. Oops.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2021-47432</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
scsi: ufs: Fix a deadlock in the error handler
|
|
|
|
The following deadlock has been observed on a test setup:
|
|
|
|
- All tags allocated
|
|
|
|
- The SCSI error handler calls ufshcd_eh_host_reset_handler()
|
|
|
|
- ufshcd_eh_host_reset_handler() queues work that calls
|
|
ufshcd_err_handler()
|
|
|
|
- ufshcd_err_handler() locks up as follows:
|
|
|
|
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
|
|
Call trace:
|
|
__switch_to+0x298/0x5d8
|
|
__schedule+0x6cc/0xa94
|
|
schedule+0x12c/0x298
|
|
blk_mq_get_tag+0x210/0x480
|
|
__blk_mq_alloc_request+0x1c8/0x284
|
|
blk_get_request+0x74/0x134
|
|
ufshcd_exec_dev_cmd+0x68/0x640
|
|
ufshcd_verify_dev_init+0x68/0x35c
|
|
ufshcd_probe_hba+0x12c/0x1cb8
|
|
ufshcd_host_reset_and_restore+0x88/0x254
|
|
ufshcd_reset_and_restore+0xd0/0x354
|
|
ufshcd_err_handler+0x408/0xc58
|
|
process_one_work+0x24c/0x66c
|
|
worker_thread+0x3e8/0xa4c
|
|
kthread+0x150/0x1b4
|
|
ret_from_fork+0x10/0x30
|
|
|
|
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
|
|
request.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2021-47622</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
net: dsa: seville: register the mdiobus under devres
|
|
|
|
As explained in commits:
|
|
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
|
|
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
|
|
|
|
mdiobus_free() will panic when called from devm_mdiobus_free() <-
|
|
devres_release_all() <- __device_release_driver(), and that mdiobus was
|
|
not previously unregistered.
|
|
|
|
The Seville VSC9959 switch is a platform device, so the initial set of
|
|
constraints that I thought would cause this (I2C or SPI buses which call
|
|
->remove on ->shutdown) do not apply. But there is one more which
|
|
applies here.
|
|
|
|
If the DSA master itself is on a bus that calls ->remove from ->shutdown
|
|
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
|
|
between the switch and the DSA master, and device_links_unbind_consumers()
|
|
will unbind the seville switch driver on shutdown.
|
|
|
|
So the same treatment must be applied to all DSA switch drivers, which
|
|
is: either use devres for both the mdiobus allocation and registration,
|
|
or don't use devres at all.
|
|
|
|
The seville driver has a code structure that could accommodate both the
|
|
mdiobus_unregister and mdiobus_free calls, but it has an external
|
|
dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls
|
|
devm_mdiobus_alloc_size() on its behalf. So rather than restructuring
|
|
that, and exporting yet one more symbol mscc_miim_teardown(), let's work
|
|
with devres and replace of_mdiobus_register with the devres variant.
|
|
When we use all-devres, we can ensure that devres doesn't free a
|
|
still-registered bus (it either runs both callbacks, or none).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48814</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
SUNRPC: lock against ->sock changing during sysfs read
|
|
|
|
->sock can be set to NULL asynchronously unless ->recv_mutex is held.
|
|
So it is important to hold that mutex. Otherwise a sysfs read can
|
|
trigger an oops.
|
|
Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before
|
|
handling sysfs reads") appears to attempt to fix this problem, but it
|
|
only narrows the race window.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48816</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
Bluetooth: hci_core: Fix leaking sent_cmd skb
|
|
|
|
sent_cmd memory is not freed before freeing hci_dev causing it to leak
|
|
it contents.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2022-48844</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
smb: client: fix potential deadlock when releasing mids
|
|
|
|
All release_mid() callers seem to hold a reference of @mid so there is
|
|
no need to call kref_put(&mid->refcount, __release_mid) under
|
|
@server->mid_lock spinlock. If they don't, then an use-after-free bug
|
|
would have occurred anyways.
|
|
|
|
By getting rid of such spinlock also fixes a potential deadlock as
|
|
shown below
|
|
|
|
CPU 0 CPU 1
|
|
------------------------------------------------------------------
|
|
cifs_demultiplex_thread() cifs_debug_data_proc_show()
|
|
release_mid()
|
|
spin_lock(&server->mid_lock);
|
|
spin_lock(&cifs_tcp_ses_lock)
|
|
spin_lock(&server->mid_lock)
|
|
__release_mid()
|
|
smb2_find_smb_tcon()
|
|
spin_lock(&cifs_tcp_ses_lock) *deadlock*</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2023-52757</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
|
|
|
|
The BOS descriptor defines a root descriptor and is the base descriptor for
|
|
accessing a family of related descriptors.
|
|
|
|
Function 'usb_get_bos_descriptor()' encounters an iteration issue when
|
|
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
|
|
the same descriptor being read repeatedly.
|
|
|
|
To address this issue, a 'goto' statement is introduced to ensure that the
|
|
pointer and the amount read is updated correctly. This ensures that the
|
|
function iterates to the next descriptor instead of reading the same
|
|
descriptor repeatedly.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2023-52781</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.3</BaseScore>
|
|
<Vector>AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
nfs: Handle error of rpc_proc_register() in nfs_net_init().
|
|
|
|
syzkaller reported a warning [0] triggered while destroying immature
|
|
netns.
|
|
|
|
rpc_proc_register() was called in init_nfs_fs(), but its error
|
|
has been ignored since at least the initial commit 1da177e4c3f4
|
|
("Linux-2.6.12-rc2").
|
|
|
|
Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
|
|
in net namespaces") converted the procfs to per-netns and made
|
|
the problem more visible.
|
|
|
|
Even when rpc_proc_register() fails, nfs_net_init() could succeed,
|
|
and thus nfs_net_exit() will be called while destroying the netns.
|
|
|
|
Then, remove_proc_entry() will be called for non-existing proc
|
|
directory and trigger the warning below.
|
|
|
|
Let's handle the error of rpc_proc_register() properly in nfs_net_init().
|
|
|
|
[0]:
|
|
name 'nfs'
|
|
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
|
|
Modules linked in:
|
|
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
|
|
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
|
|
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
|
|
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
|
|
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
|
|
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
|
|
FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
|
|
nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
|
|
ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
|
|
setup_net+0x46c/0x660 net/core/net_namespace.c:372
|
|
copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
|
|
create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
|
|
unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
|
|
ksys_unshare+0x342/0x760 kernel/fork.c:3322
|
|
__do_sys_unshare kernel/fork.c:3393 [inline]
|
|
__se_sys_unshare kernel/fork.c:3391 [inline]
|
|
__x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0x7f30d0febe5d
|
|
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
|
|
RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
|
|
RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
|
|
R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-36939</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.6</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
scsi: qedf: Ensure the copied buf is NUL terminated
|
|
|
|
Currently, we allocate a count-sized kernel buffer and copy count from
|
|
userspace to that buffer. Later, we use kstrtouint on this buffer but we
|
|
don't ensure that the string is terminated inside the buffer, this can
|
|
lead to OOB read when using kstrtouint. Fix this issue by using
|
|
memdup_user_nul instead of memdup_user.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38559</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group
|
|
|
|
The perf tool allows users to create event groups through following
|
|
cmd [1], but the driver does not check whether the array index is out
|
|
of bounds when writing data to the event_group array. If the number of
|
|
events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the
|
|
memory write overflow of event_group array occurs.
|
|
|
|
Add array index check to fix the possible array out of bounds violation,
|
|
and return directly when write new events are written to array bounds.
|
|
|
|
There are 9 different events in an event_group.
|
|
[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38568</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/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-1896</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:
|
|
|
|
ecryptfs: Fix buffer size for tag 66 packet
|
|
|
|
The 'TAG 66 Packet Format' description is missing the cipher code and
|
|
checksum fields that are packed into the message packet. As a result,
|
|
the buffer allocated for the packet is 3 bytes too small and
|
|
write_tag_66_packet() will write up to 3 bytes past the end of the
|
|
buffer.
|
|
|
|
Fix this by increasing the size of the allocation so the whole packet
|
|
will always fit in the buffer.
|
|
|
|
This fixes the below kasan slab-out-of-bounds bug:
|
|
|
|
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
|
|
|
|
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x4c/0x70
|
|
print_report+0xc5/0x610
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? kasan_complete_mode_report_info+0x44/0x210
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
kasan_report+0xc2/0x110
|
|
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
__asan_store1+0x62/0x80
|
|
ecryptfs_generate_key_packet_set+0x7d6/0xde0
|
|
? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
|
|
? __alloc_pages+0x2e2/0x540
|
|
? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
|
|
? dentry_open+0x8f/0xd0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
? __pfx_ecryptfs_write_metadata+0x10/0x10
|
|
? ecryptfs_get_lower_file+0x6b/0x190
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
? __pfx_path_openat+0x10/0x10
|
|
do_filp_open+0x15e/0x290
|
|
? __pfx_do_filp_open+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? _raw_spin_lock+0x86/0xf0
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? __kasan_check_write+0x18/0x30
|
|
? alloc_fd+0xf4/0x330
|
|
do_sys_openat2+0x122/0x160
|
|
? __pfx_do_sys_openat2+0x10/0x10
|
|
__x64_sys_openat+0xef/0x170
|
|
? __pfx___x64_sys_openat+0x10/0x10
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
RIP: 0033:0x7f00a703fd67
|
|
Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
|
|
RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
|
|
RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
|
|
RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
|
|
RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
|
|
R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
|
|
</TASK>
|
|
|
|
Allocated by task 181:
|
|
kasan_save_stack+0x2f/0x60
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x25/0x40
|
|
__kasan_kmalloc+0xc5/0xd0
|
|
__kmalloc+0x66/0x160
|
|
ecryptfs_generate_key_packet_set+0x6d2/0xde0
|
|
ecryptfs_write_metadata+0x30a/0x550
|
|
ecryptfs_initialize_file+0x77/0x150
|
|
ecryptfs_create+0x1c2/0x2f0
|
|
path_openat+0x17cf/0x1ba0
|
|
do_filp_open+0x15e/0x290
|
|
do_sys_openat2+0x122/0x160
|
|
__x64_sys_openat+0xef/0x170
|
|
do_syscall_64+0x60/0xd0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38578</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.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-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
ALSA: timer: Set lower bound of start tick time
|
|
|
|
Currently ALSA timer doesn't have the lower limit of the start tick
|
|
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
|
|
for hrtimer. Such a situation may lead to an unexpected RCU stall,
|
|
where the callback repeatedly queuing the expire update, as reported
|
|
by fuzzer.
|
|
|
|
This patch introduces a sanity check of the timer start tick time, so
|
|
that the system returns an error when a too small start size is set.
|
|
As of this patch, the lower limit is hard-coded to 100us, which is
|
|
small enough but can still work somehow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38618</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
usb-storage: alauda: Check whether the media is initialized
|
|
|
|
The member "uzonesize" of struct alauda_info will remain 0
|
|
if alauda_init_media() fails, potentially causing divide errors
|
|
in alauda_read_data() and alauda_write_lba().
|
|
- Add a member "media_initialized" to struct alauda_info.
|
|
- Change a condition in alauda_check_media() to ensure the
|
|
first initialization.
|
|
- Add an error check for the return value of alauda_init_media().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-38619</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
|
|
|
|
The error handling in nilfs_empty_dir() when a directory folio/page read
|
|
fails is incorrect, as in the old ext2 implementation, and if the
|
|
folio/page cannot be read or nilfs_check_folio() fails, it will falsely
|
|
determine the directory as empty and corrupt the file system.
|
|
|
|
In addition, since nilfs_empty_dir() does not immediately return on a
|
|
failed folio/page read, but continues to loop, this can cause a long loop
|
|
with I/O if i_size of the directory's inode is also corrupted, causing the
|
|
log writer thread to wait and hang, as reported by syzbot.
|
|
|
|
Fix these issues by making nilfs_empty_dir() immediately return a false
|
|
value (0) if it fails to get a directory folio/page.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39469</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa ( xfs: detect and handle invalid iclog size set bymkfs ) added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions. Later commit 0c771b99d6c9( xfs: clean up calculation of LR header blocks ) cleaned up the logreover buffer calculation, but stoped using the fixed up h_size valueto size the log recovery buffer, which can lead to an out of boundsaccess when the incorrect h_size does not come from the old mkfstool, but a fuzzer.Fix this by open coding xlog_logrec_hblks and taking the fixed h_sizeinto account for this calculation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39472</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
drm/komeda: check for error-valued pointer
|
|
|
|
komeda_pipeline_get_state() may return an error-valued pointer, thus
|
|
check the pointer for negative or null value before dereferencing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-39505</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
ipv6: fix possible race in __fib6_drop_pcpu_from()
|
|
|
|
syzbot found a race in __fib6_drop_pcpu_from() [1]
|
|
|
|
If compiler reads more than once (*ppcpu_rt),
|
|
second read could read NULL, if another cpu clears
|
|
the value in rt6_get_pcpu_route().
|
|
|
|
Add a READ_ONCE() to prevent this race.
|
|
|
|
Also add rcu_read_lock()/rcu_read_unlock() because
|
|
we rely on RCU protection while dereferencing pcpu_rt.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
|
|
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
Workqueue: netns cleanup_net
|
|
RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
|
|
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
|
|
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
|
|
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
|
|
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
|
|
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
|
|
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
|
|
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
|
|
FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
__fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
|
|
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
|
|
fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
|
|
fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
|
|
fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
|
|
fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
|
|
fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
|
|
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
|
|
fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
|
|
__fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
|
|
rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
|
|
rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
|
|
addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
|
|
addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
|
|
notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
|
|
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
|
|
call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
|
|
call_netdevice_notifiers net/core/dev.c:2044 [inline]
|
|
dev_close_many+0x333/0x6a0 net/core/dev.c:1585
|
|
unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
|
|
unregister_netdevice_many net/core/dev.c:11276 [inline]
|
|
default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
|
|
ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
|
|
cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
|
|
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
|
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
|
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
|
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40905</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</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-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</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:
|
|
|
|
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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</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-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</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-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tipc: force a dst refcount before doing decryption
|
|
|
|
As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before
|
|
entering the xfrm type handlers"):
|
|
|
|
"Crypto requests might return asynchronous. In this case we leave the
|
|
rcu protected region, so force a refcount on the skb's destination
|
|
entry before we enter the xfrm type input/output handlers."
|
|
|
|
On TIPC decryption path it has the same problem, and skb_dst_force()
|
|
should be called before doing decryption to avoid a possible crash.
|
|
|
|
Shuang reported this issue when this warning is triggered:
|
|
|
|
[] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
|
|
[] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
|
|
[] Workqueue: crypto cryptd_queue_worker
|
|
[] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
|
|
[] Call Trace:
|
|
[] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
|
|
[] tipc_rcv+0xcf5/0x1060 [tipc]
|
|
[] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
|
|
[] cryptd_aead_crypt+0xdb/0x190
|
|
[] cryptd_queue_worker+0xed/0x190
|
|
[] process_one_work+0x93d/0x17e0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-40983</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing: Build event generation tests only as modules
|
|
|
|
The kprobes and synth event generation test modules add events and lock
|
|
(get a reference) those event file reference in module init function,
|
|
and unlock and delete it in module exit function. This is because those
|
|
are designed for playing as modules.
|
|
|
|
If we make those modules as built-in, those events are left locked in the
|
|
kernel, and never be removed. This causes kprobe event self-test failure
|
|
as below.
|
|
|
|
[ 97.349708] ------------[ cut here ]------------
|
|
[ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.357106] Modules linked in:
|
|
[ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14
|
|
[ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
[ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90
|
|
[ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286
|
|
[ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000
|
|
[ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68
|
|
[ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
[ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000
|
|
[ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000
|
|
[ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
|
|
[ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0
|
|
[ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 97.391196] Call Trace:
|
|
[ 97.391967] <TASK>
|
|
[ 97.392647] ? __warn+0xcc/0x180
|
|
[ 97.393640] ? kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.395181] ? report_bug+0xbd/0x150
|
|
[ 97.396234] ? handle_bug+0x3e/0x60
|
|
[ 97.397311] ? exc_invalid_op+0x1a/0x50
|
|
[ 97.398434] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 97.399652] ? trace_kprobe_is_busy+0x20/0x20
|
|
[ 97.400904] ? tracing_reset_all_online_cpus+0x15/0x90
|
|
[ 97.402304] ? kprobe_trace_self_tests_init+0x3f1/0x480
|
|
[ 97.403773] ? init_kprobe_trace+0x50/0x50
|
|
[ 97.404972] do_one_initcall+0x112/0x240
|
|
[ 97.406113] do_initcall_level+0x95/0xb0
|
|
[ 97.407286] ? kernel_init+0x1a/0x1a0
|
|
[ 97.408401] do_initcalls+0x3f/0x70
|
|
[ 97.409452] kernel_init_freeable+0x16f/0x1e0
|
|
[ 97.410662] ? rest_init+0x1f0/0x1f0
|
|
[ 97.411738] kernel_init+0x1a/0x1a0
|
|
[ 97.412788] ret_from_fork+0x39/0x50
|
|
[ 97.413817] ? rest_init+0x1f0/0x1f0
|
|
[ 97.414844] ret_from_fork_asm+0x11/0x20
|
|
[ 97.416285] </TASK>
|
|
[ 97.417134] irq event stamp: 13437323
|
|
[ 97.418376] hardirqs last enabled at (13437337): [<ffffffff8110bc0c>] console_unlock+0x11c/0x150
|
|
[ 97.421285] hardirqs last disabled at (13437370): [<ffffffff8110bbf1>] console_unlock+0x101/0x150
|
|
[ 97.423838] softirqs last enabled at (13437366): [<ffffffff8108e17f>] handle_softirqs+0x23f/0x2a0
|
|
[ 97.426450] softirqs last disabled at (13437393): [<ffffffff8108e346>] __irq_exit_rcu+0x66/0xd0
|
|
[ 97.428850] ---[ end trace 0000000000000000 ]---
|
|
|
|
And also, since we can not cleanup dynamic_event file, ftracetest are
|
|
failed too.
|
|
|
|
To avoid these issues, build these tests only as modules.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-41004</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="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-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" 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:bpf: Fix overrunning reservations in ringbufThe BPF ring buffer internally is implemented as a power-of-2 sized circularbuffer, with two logical and ever-increasing counters: consumer_pos is theconsumer counter to show which logical position the consumer consumed thedata, and producer_pos which is the producer counter denoting the amount ofdata reserved by all producers.Each time a record is reserved, the producer that owns the record willsuccessfully advance producer counter. In user space each time a record isread, the consumer of the data advanced the consumer counter once it finishedprocessing. Both counters are stored in separate pages so that from userspace, the producer counter is read-only and the consumer counter is read-write.One aspect that simplifies and thus speeds up the implementation of bothproducers and consumers is how the data area is mapped twice contiguouslyback-to-back in the virtual memory, allowing to not take any special measuresfor samples that have to wrap around at the end of the circular buffer dataarea, because the next page after the last data page would be first data pageagain, and thus the sample will still appear completely contiguous in virtualmemory.Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header forbook-keeping the length and offset, and is inaccessible to the BPF program.Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`for the BPF program to use. Bing-Jhong and Muhammad reported that it is howeverpossible to make a second allocated memory chunk overlapping with the firstchunk and as a result, the BPF program is now able to edit first chunk sheader.For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with sizeof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call tobpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, letsallocate a chunk B with size 0x3000. This will succeed because consumer_poswas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`check. Chunk B will be in range [0x3008,0x6010], and the BPF program is ableto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentionedearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same datapages. This means that chunk B at [0x4000,0x4008] is chunk A s header.bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header s pg_off to thenlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunkB modified chunk A s header, then bpf_ringbuf_commit() refers to the wrongpage and could cause a crash.Fix it by calculating the oldest pending_pos and check whether the rangefrom the oldest outstanding record to the newest would span beyond the ringbuffer size. If that is the case, then reject the request. We ve tested withthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)before/after the fix and while it seems a bit slower on some benchmarks, itis still not significantly enough to matter.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-26</ReleaseDate>
|
|
<CVE>CVE-2024-41009</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-26</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1896</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |