6159 lines
270 KiB
XML
6159 lines
270 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1618</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-17</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-17</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-17</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-17</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tun: avoid double free in tun_free_netdev
|
|
|
|
Avoid double free in tun_free_netdev() by moving the
|
|
dev->tstats and tun->security allocs to a new ndo_init routine
|
|
(tun_net_init()) that will be called by register_netdevice().
|
|
ndo_init is paired with the desctructor (tun_free_netdev()),
|
|
so if there's an error in register_netdevice() the destructor
|
|
will handle the frees.
|
|
|
|
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
|
|
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
|
|
Hardware name: Red Hat KVM, BIOS
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
|
|
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
|
|
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
|
|
____kasan_slab_free mm/kasan/common.c:346 [inline]
|
|
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
|
|
kasan_slab_free include/linux/kasan.h:235 [inline]
|
|
slab_free_hook mm/slub.c:1723 [inline]
|
|
slab_free_freelist_hook mm/slub.c:1749 [inline]
|
|
slab_free mm/slub.c:3513 [inline]
|
|
kfree+0xac/0x2d0 mm/slub.c:4561
|
|
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
|
|
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
|
|
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
|
|
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
|
|
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
|
|
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:874 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:860 [inline]
|
|
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/kvm: Disable kvmclock on all CPUs on shutdown
|
|
|
|
Currenly, we disable kvmclock from machine_shutdown() hook and this
|
|
only happens for boot CPU. We need to disable it for all CPUs to
|
|
guard against memory corruption e.g. on restore from hibernate.
|
|
|
|
Note, writing '0' to kvmclock MSR doesn't clear memory location, it
|
|
just prevents hypervisor from updating the location so for the short
|
|
while after write and while CPU is still alive, the clock remains usable
|
|
and correct so we don't need to switch to some other clocksource.(CVE-2021-47110)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Fix NULL ptr dereference on VSI filter sync
|
|
|
|
Remove the reason of null pointer dereference in sync VSI filters.
|
|
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
|
|
of VSI resources to sync this thread with sync filters subtask.
|
|
Without this patch it is possible to start update the VSI filter list
|
|
after VSI is removed, that's causing a kernel oops.(CVE-2021-47184)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
erofs: fix pcluster use-after-free on UP platforms
|
|
|
|
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
|
|
Read of size 8 at addr ffff8881094223f8 by task stress/7789
|
|
|
|
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
Call Trace:
|
|
<TASK>
|
|
..
|
|
__mutex_lock+0xe5/0xc30
|
|
..
|
|
z_erofs_do_read_page+0x8ce/0x1560
|
|
..
|
|
z_erofs_readahead+0x31c/0x580
|
|
..
|
|
Freed by task 7787
|
|
kasan_save_stack+0x1e/0x40
|
|
kasan_set_track+0x20/0x30
|
|
kasan_set_free_info+0x20/0x40
|
|
__kasan_slab_free+0x10c/0x190
|
|
kmem_cache_free+0xed/0x380
|
|
rcu_core+0x3d5/0xc90
|
|
__do_softirq+0x12d/0x389
|
|
|
|
Last potentially related work creation:
|
|
kasan_save_stack+0x1e/0x40
|
|
__kasan_record_aux_stack+0x97/0xb0
|
|
call_rcu+0x3d/0x3f0
|
|
erofs_shrink_workstation+0x11f/0x210
|
|
erofs_shrink_scan+0xdc/0x170
|
|
shrink_slab.constprop.0+0x296/0x530
|
|
drop_slab+0x1c/0x70
|
|
drop_caches_sysctl_handler+0x70/0x80
|
|
proc_sys_call_handler+0x20a/0x2f0
|
|
vfs_write+0x555/0x6c0
|
|
ksys_write+0xbe/0x160
|
|
do_syscall_64+0x3b/0x90
|
|
|
|
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
|
|
orig_val thus it causes a race that the pcluster reuses unexpectedly
|
|
before freeing.
|
|
|
|
Since UP platforms are quite rare now, such path becomes unnecessary.
|
|
Let's drop such specific-designed path directly instead.(CVE-2022-48674)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
|
|
|
|
There is a dead-lock in the hwrng device read path. This triggers
|
|
when the user reads from /dev/hwrng into memory also mmap-ed from
|
|
/dev/hwrng. The resulting page fault triggers a recursive read
|
|
which then dead-locks.
|
|
|
|
Fix this by using a stack buffer when calling copy_to_user.(CVE-2023-52615)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.(CVE-2023-52620)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: Fix a suspicious RCU usage warning
|
|
|
|
I received the following warning while running cthon against an ontap
|
|
server running pNFS:
|
|
|
|
[ 57.202521] =============================
|
|
[ 57.202522] WARNING: suspicious RCU usage
|
|
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
|
|
[ 57.202525] -----------------------------
|
|
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
|
|
[ 57.202527]
|
|
other info that might help us debug this:
|
|
|
|
[ 57.202528]
|
|
rcu_scheduler_active = 2, debug_locks = 1
|
|
[ 57.202529] no locks held by test5/3567.
|
|
[ 57.202530]
|
|
stack backtrace:
|
|
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
|
|
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
|
|
[ 57.202536] Call Trace:
|
|
[ 57.202537] <TASK>
|
|
[ 57.202540] dump_stack_lvl+0x77/0xb0
|
|
[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0
|
|
[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
|
|
[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
|
|
[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202866] write_cache_pages+0x265/0x450
|
|
[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202913] do_writepages+0xd2/0x230
|
|
[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80
|
|
[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80
|
|
[ 57.202924] filemap_write_and_wait_range+0xd9/0x170
|
|
[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202969] __se_sys_close+0x46/0xd0
|
|
[ 57.202972] do_syscall_64+0x68/0x100
|
|
[ 57.202975] ? do_syscall_64+0x77/0x100
|
|
[ 57.202976] ? do_syscall_64+0x77/0x100
|
|
[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
[ 57.202982] RIP: 0033:0x7fe2b12e4a94
|
|
[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
|
|
[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
|
|
[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
|
|
[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
|
|
[ 57.202993] R10: 00007f
|
|
---truncated---(CVE-2023-52623)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
|
|
|
|
The original code puts flush_work() before timer_shutdown_sync()
|
|
in switch_drv_remove(). Although we use flush_work() to stop
|
|
the worker, it could be rescheduled in switch_timer(). As a result,
|
|
a use-after-free bug can occur. The details are shown below:
|
|
|
|
(cpu 0) | (cpu 1)
|
|
switch_drv_remove() |
|
|
flush_work() |
|
|
... | switch_timer // timer
|
|
| schedule_work(&psw->work)
|
|
timer_shutdown_sync() |
|
|
... | switch_work_handler // worker
|
|
kfree(psw) // free |
|
|
| psw->state = 0 // use
|
|
|
|
This patch puts timer_shutdown_sync() before flush_work() to
|
|
mitigate the bugs. As a result, the worker and timer will be
|
|
stopped safely before the deallocate operations.(CVE-2023-52629)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
|
|
|
|
There is a chance if a frequent switch of the governor
|
|
done in a loop result in timer list corruption where
|
|
timer cancel being done from two place one from
|
|
cancel_delayed_work_sync() and followed by expire_timers()
|
|
can be seen from the traces[1].
|
|
|
|
while true
|
|
do
|
|
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
|
|
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
|
|
done
|
|
|
|
It looks to be issue with devfreq driver where
|
|
device_monitor_[start/stop] need to synchronized so that
|
|
delayed work should get corrupted while it is either
|
|
being queued or running or being cancelled.
|
|
|
|
Let's use polling flag and devfreq lock to synchronize the
|
|
queueing the timer instance twice and work data being
|
|
corrupted.
|
|
|
|
[1]
|
|
...
|
|
..
|
|
<idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
|
|
<idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
|
|
<idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
|
|
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
|
|
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
|
|
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
|
|
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
|
|
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
|
|
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
|
|
|
|
[2]
|
|
|
|
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
|
|
[ 9436.261664][ C4] Mem abort info:
|
|
[ 9436.261666][ C4] ESR = 0x96000044
|
|
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
|
|
[ 9436.261671][ C4] SET = 0, FnV = 0
|
|
[ 9436.261673][ C4] EA = 0, S1PTW = 0
|
|
[ 9436.261675][ C4] Data abort info:
|
|
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
|
|
[ 9436.261680][ C4] CM = 0, WnR = 1
|
|
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
|
|
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
|
|
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
|
|
...
|
|
|
|
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
|
|
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
|
|
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
|
|
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
|
|
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
|
|
[ 9436.262168][ C4] sp : ffffffc010023dd0
|
|
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
|
|
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
|
|
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
|
|
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
|
|
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
|
|
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
|
|
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
|
|
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
|
|
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
|
|
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
|
|
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
|
|
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
|
|
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
|
|
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
|
|
---truncated---(CVE-2023-52635)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
|
|
|
|
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
|
|
modifies jsk->filters while receiving packets.
|
|
|
|
Following trace was seen on affected system:
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
Read of size 4 at addr ffff888012144014 by task j1939/350
|
|
|
|
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
print_report+0xd3/0x620
|
|
? kasan_complete_mode_report_info+0x7d/0x200
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
kasan_report+0xc2/0x100
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
__asan_load4+0x84/0xb0
|
|
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
j1939_sk_recv+0x20b/0x320 [can_j1939]
|
|
? __kasan_check_write+0x18/0x20
|
|
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
|
|
? j1939_simple_recv+0x69/0x280 [can_j1939]
|
|
? j1939_ac_recv+0x5e/0x310 [can_j1939]
|
|
j1939_can_recv+0x43f/0x580 [can_j1939]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
? raw_rcv+0x42/0x3c0 [can_raw]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
can_rcv_filter+0x11f/0x350 [can]
|
|
can_receive+0x12f/0x190 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
can_rcv+0xdd/0x130 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
__netif_receive_skb_one_core+0x13d/0x150
|
|
? __pfx___netif_receive_skb_one_core+0x10/0x10
|
|
? __kasan_check_write+0x18/0x20
|
|
? _raw_spin_lock_irq+0x8c/0xe0
|
|
__netif_receive_skb+0x23/0xb0
|
|
process_backlog+0x107/0x260
|
|
__napi_poll+0x69/0x310
|
|
net_rx_action+0x2a1/0x580
|
|
? __pfx_net_rx_action+0x10/0x10
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? handle_irq_event+0x7d/0xa0
|
|
__do_softirq+0xf3/0x3f8
|
|
do_softirq+0x53/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x6e/0x70
|
|
netif_rx+0x16b/0x180
|
|
can_send+0x32b/0x520 [can]
|
|
? __pfx_can_send+0x10/0x10 [can]
|
|
? __check_object_size+0x299/0x410
|
|
raw_sendmsg+0x572/0x6d0 [can_raw]
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
? apparmor_socket_sendmsg+0x2f/0x40
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
sock_sendmsg+0xef/0x100
|
|
sock_write_iter+0x162/0x220
|
|
? __pfx_sock_write_iter+0x10/0x10
|
|
? __rtnl_unlock+0x47/0x80
|
|
? security_file_permission+0x54/0x320
|
|
vfs_write+0x6ba/0x750
|
|
? __pfx_vfs_write+0x10/0x10
|
|
? __fget_light+0x1ca/0x1f0
|
|
? __rcu_read_unlock+0x5b/0x280
|
|
ksys_write+0x143/0x170
|
|
? __pfx_ksys_write+0x10/0x10
|
|
? __kasan_check_read+0x15/0x20
|
|
? fpregs_assert_state_consistent+0x62/0x70
|
|
__x64_sys_write+0x47/0x60
|
|
do_syscall_64+0x60/0x90
|
|
? do_syscall_64+0x6d/0x90
|
|
? irqentry_exit+0x3f/0x50
|
|
? exc_page_fault+0x79/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Allocated by task 348:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x1f/0x30
|
|
__kasan_kmalloc+0xb5/0xc0
|
|
__kmalloc_node_track_caller+0x67/0x160
|
|
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Freed by task 349:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_free_info+0x2f/0x50
|
|
__kasan_slab_free+0x12e/0x1c0
|
|
__kmem_cache_free+0x1b9/0x380
|
|
kfree+0x7a/0x120
|
|
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
|
|
|
|
The following 3 locks would race against each other, causing the
|
|
deadlock situation in the Syzbot bug report:
|
|
|
|
- j1939_socks_lock
|
|
- active_session_list_lock
|
|
- sk_session_queue_lock
|
|
|
|
A reasonable fix is to change j1939_socks_lock to an rwlock, since in
|
|
the rare situations where a write lock is required for the linked list
|
|
that j1939_socks_lock is protecting, the code does not attempt to
|
|
acquire any more locks. This would break the circular lock dependency,
|
|
where, for example, the current thread already locks j1939_socks_lock
|
|
and attempts to acquire sk_session_queue_lock, and at the same time,
|
|
another thread attempts to acquire j1939_socks_lock while holding
|
|
sk_session_queue_lock.
|
|
|
|
NOTE: This patch along does not fix the unregister_netdevice bug
|
|
reported by Syzbot; instead, it solves a deadlock situation to prepare
|
|
for one or more further patches to actually fix the Syzbot bug, which
|
|
appears to be a reference counting problem within the j1939 codebase.
|
|
|
|
[mkl: remove unrelated newline change](CVE-2023-52638)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: s390: vsie: fix race during shadow creation
|
|
|
|
Right now it is possible to see gmap->private being zero in
|
|
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
|
|
fact that we add gmap->private == kvm after creation:
|
|
|
|
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
|
|
struct vsie_page *vsie_page)
|
|
{
|
|
[...]
|
|
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
|
|
if (IS_ERR(gmap))
|
|
return PTR_ERR(gmap);
|
|
gmap->private = vcpu->kvm;
|
|
|
|
Let children inherit the private field of the parent.(CVE-2023-52639)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
|
|
|
|
When QoS is disabled, the queue priority value will not map to the correct
|
|
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
|
|
is disabled to prevent trying to stop/wake a non-existent queue and failing
|
|
to stop/wake the actual queue instantiated.
|
|
|
|
Log of issue before change (with kernel parameter qos=0):
|
|
[ +5.112651] ------------[ cut here ]------------
|
|
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
|
|
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
|
|
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
|
|
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
|
|
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
|
|
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
|
|
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
|
|
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
|
|
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
|
|
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
|
|
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
|
|
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
|
|
[ +0.000001] CS: 0010 DS: 0
|
|
---truncated---(CVE-2023-52644)
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)
|
|
|
|
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
|
|
|
|
|
|
|
|
|
|
(CVE-2024-24858)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: make sure init the accept_queue's spinlocks once
|
|
|
|
When I run syz's reproduction C program locally, it causes the following
|
|
issue:
|
|
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
|
|
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
|
|
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
|
|
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
|
|
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
|
|
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
|
|
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
|
|
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
|
|
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<IRQ>
|
|
_raw_spin_unlock (kernel/locking/spinlock.c:186)
|
|
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
|
|
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
|
|
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
|
|
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
|
|
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
|
|
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
|
|
__netif_receive_skb_one_core (net/core/dev.c:5529)
|
|
process_backlog (./include/linux/rcupdate.h:779)
|
|
__napi_poll (net/core/dev.c:6533)
|
|
net_rx_action (net/core/dev.c:6604)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
|
|
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip (kernel/softirq.c:381)
|
|
__dev_queue_xmit (net/core/dev.c:4374)
|
|
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
|
|
__ip_queue_xmit (net/ipv4/ip_output.c:535)
|
|
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
|
|
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
|
|
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
|
|
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
|
|
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
|
|
release_sock (net/core/sock.c:3536)
|
|
inet_wait_for_connect (net/ipv4/af_inet.c:609)
|
|
__inet_stream_connect (net/ipv4/af_inet.c:702)
|
|
inet_stream_connect (net/ipv4/af_inet.c:748)
|
|
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
|
|
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
|
|
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
RIP: 0033:0x7fa10ff05a3d
|
|
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 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 ab a3 0e 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
|
|
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
|
|
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
|
|
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
|
|
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
|
|
</TASK>
|
|
|
|
The issue triggering process is analyzed as follows:
|
|
Thread A Thread B
|
|
tcp_v4_rcv //receive ack TCP packet inet_shutdown
|
|
tcp_check_req tcp_disconnect //disconnect sock
|
|
... tcp_set_state(sk, TCP_CLOSE)
|
|
inet_csk_complete_hashdance ...
|
|
inet_csk_reqsk_queue_add
|
|
---truncated---(CVE-2024-26614)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow anonymous set with timeout flag
|
|
|
|
Anonymous sets are never used with timeout from userspace, reject this.
|
|
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing: Ensure visibility when inserting an element into tracing_map
|
|
|
|
Running the following two commands in parallel on a multi-processor
|
|
AArch64 machine can sporadically produce an unexpected warning about
|
|
duplicate histogram entries:
|
|
|
|
$ while true; do
|
|
echo hist:key=id.syscall:val=hitcount > \
|
|
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
|
|
cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
|
|
sleep 0.001
|
|
done
|
|
$ stress-ng --sysbadaddr $(nproc)
|
|
|
|
The warning looks as follows:
|
|
|
|
[ 2911.172474] ------------[ cut here ]------------
|
|
[ 2911.173111] Duplicates detected: 1
|
|
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
|
|
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
|
|
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
|
|
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
|
|
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.185310] sp : ffff8000a1513900
|
|
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
|
|
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
|
|
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
|
|
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
|
|
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
|
|
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
|
|
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
|
|
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
|
|
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
|
|
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
|
|
[ 2911.194259] Call trace:
|
|
[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.195220] hist_show+0x124/0x800
|
|
[ 2911.195692] seq_read_iter+0x1d4/0x4e8
|
|
[ 2911.196193] seq_read+0xe8/0x138
|
|
[ 2911.196638] vfs_read+0xc8/0x300
|
|
[ 2911.197078] ksys_read+0x70/0x108
|
|
[ 2911.197534] __arm64_sys_read+0x24/0x38
|
|
[ 2911.198046] invoke_syscall+0x78/0x108
|
|
[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8
|
|
[ 2911.199157] do_el0_svc+0x28/0x40
|
|
[ 2911.199613] el0_svc+0x40/0x178
|
|
[ 2911.200048] el0t_64_sync_handler+0x13c/0x158
|
|
[ 2911.200621] el0t_64_sync+0x1a8/0x1b0
|
|
[ 2911.201115] ---[ end trace 0000000000000000 ]---
|
|
|
|
The problem appears to be caused by CPU reordering of writes issued from
|
|
__tracing_map_insert().
|
|
|
|
The check for the presence of an element with a given key in this
|
|
function is:
|
|
|
|
val = READ_ONCE(entry->val);
|
|
if (val && keys_match(key, val->key, map->key_size)) ...
|
|
|
|
The write of a new entry is:
|
|
|
|
elt = get_free_elt(map);
|
|
memcpy(elt->key, key, map->key_size);
|
|
entry->val = elt;
|
|
|
|
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
|
|
stores may become visible in the reversed order on another CPU. This
|
|
second CPU might then incorrectly determine that a new key doesn't match
|
|
an already present val->key and subse
|
|
---truncated---(CVE-2024-26645)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.(CVE-2024-26671)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppp_async: limit MRU to 64K
|
|
|
|
syzbot triggered a warning [1] in __alloc_pages():
|
|
|
|
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
|
|
|
|
Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
|
|
|
|
Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
|
|
|
|
[1]:
|
|
|
|
WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
Modules linked in:
|
|
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
Workqueue: events_unbound flush_to_ldisc
|
|
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
|
|
sp : ffff800093967580
|
|
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
|
|
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
|
|
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
|
|
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
|
|
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
|
|
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
|
|
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
|
|
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
|
|
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
|
|
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
|
|
Call trace:
|
|
__alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
__kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
|
|
__do_kmalloc_node mm/slub.c:3969 [inline]
|
|
__kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
|
|
kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
|
|
__alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
|
|
__netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
|
|
netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
|
|
dev_alloc_skb include/linux/skbuff.h:3248 [inline]
|
|
ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
|
|
ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
|
|
tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
|
|
tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
|
|
receive_buf drivers/tty/tty_buffer.c:444 [inline]
|
|
flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
|
|
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
|
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
|
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
|
kthread+0x288/0x310 kernel/kthread.c:388
|
|
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860(CVE-2024-26675)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: read sk->sk_family once in inet_recv_error()
|
|
|
|
inet_recv_error() is called without holding the socket lock.
|
|
|
|
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
|
|
socket option and trigger a KCSAN warning.(CVE-2024-26679)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential bug in end_buffer_async_write
|
|
|
|
According to a syzbot report, end_buffer_async_write(), which handles the
|
|
completion of block device writes, may detect abnormal condition of the
|
|
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
|
|
|
|
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
|
|
flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
|
|
with race condition of competition between segments for dirty blocks") as
|
|
a means of resolving double list insertion of dirty blocks in
|
|
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
|
|
resulting crash.
|
|
|
|
This modification is safe as long as it is used for file data and b-tree
|
|
node blocks where the page caches are independent. However, it was
|
|
irrelevant and redundant to also introduce async_write for segment summary
|
|
and super root blocks that share buffers with the backing device. This
|
|
led to the possibility that the BUG_ON check in end_buffer_async_write
|
|
would fail as described above, if independent writebacks of the backing
|
|
device occurred in parallel.
|
|
|
|
The use of async_write for segment summary buffers has already been
|
|
removed in a previous change.
|
|
|
|
Fix this issue by removing the manipulation of the async_write flag for
|
|
the remaining super root block buffer.(CVE-2024-26685)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
|
|
|
|
lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call
|
|
do_task_stat() at the same time and the process has NR_THREADS, it will
|
|
spin with irqs disabled O(NR_CPUS * NR_THREADS) time.
|
|
|
|
Change do_task_stat() to use sig->stats_lock to gather the statistics
|
|
outside of ->siglock protected section, in the likely case this code will
|
|
run lockless.(CVE-2024-26686)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix data corruption in dsync block recovery for small block sizes
|
|
|
|
The helper function nilfs_recovery_copy_block() of
|
|
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
|
|
data sync writes during a mount after an unclean shutdown, incorrectly
|
|
calculates the on-page offset when copying repair data to the file's page
|
|
cache. In environments where the block size is smaller than the page
|
|
size, this flaw can cause data corruption and leak uninitialized memory
|
|
bytes during the recovery process.
|
|
|
|
Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
|
|
|
|
(struct dirty_throttle_control *)->thresh is an unsigned long, but is
|
|
passed as the u32 divisor argument to div_u64(). On architectures where
|
|
unsigned long is 64 bytes, the argument will be implicitly truncated.
|
|
|
|
Use div64_u64() instead of div_u64() so that the value used in the "is
|
|
this a safe division" check is the same as the divisor.
|
|
|
|
Also, remove redundant cast of the numerator to u64, as that should happen
|
|
implicitly.
|
|
|
|
This would be difficult to exploit in memcg domain, given the ratio-based
|
|
arithmetic domain_drity_limits() uses, but is much easier in global
|
|
writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
|
|
vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't drop extent_map for free space inode on write error
|
|
|
|
While running the CI for an unrelated change I hit the following panic
|
|
with generic/648 on btrfs_holes_spacecache.
|
|
|
|
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/extent_io.c:1385!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
|
|
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
|
|
Call Trace:
|
|
<TASK>
|
|
extent_write_cache_pages+0x2ac/0x8f0
|
|
extent_writepages+0x87/0x110
|
|
do_writepages+0xd5/0x1f0
|
|
filemap_fdatawrite_wbc+0x63/0x90
|
|
__filemap_fdatawrite_range+0x5c/0x80
|
|
btrfs_fdatawrite_range+0x1f/0x50
|
|
btrfs_write_out_cache+0x507/0x560
|
|
btrfs_write_dirty_block_groups+0x32a/0x420
|
|
commit_cowonly_roots+0x21b/0x290
|
|
btrfs_commit_transaction+0x813/0x1360
|
|
btrfs_sync_file+0x51a/0x640
|
|
__x64_sys_fdatasync+0x52/0x90
|
|
do_syscall_64+0x9c/0x190
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
This happens because we fail to write out the free space cache in one
|
|
instance, come back around and attempt to write it again. However on
|
|
the second pass through we go to call btrfs_get_extent() on the inode to
|
|
get the extent mapping. Because this is a new block group, and with the
|
|
free space inode we always search the commit root to avoid deadlocking
|
|
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
|
|
requested range.
|
|
|
|
This happens because the first time we try to write the space cache out
|
|
we hit an error, and on an error we drop the extent mapping. This is
|
|
normal for normal files, but the free space cache inode is special. We
|
|
always expect the extent map to be correct. Thus the second time
|
|
through we end up with a bogus extent map.
|
|
|
|
Since we're deprecating this feature, the most straightforward way to
|
|
fix this is to simply skip dropping the extent map range for this failed
|
|
range.
|
|
|
|
I shortened the test by using error injection to stress the area to make
|
|
it easier to reproduce. With this patch in place we no longer panic
|
|
with my error injection test.(CVE-2024-26726)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arp: Prevent overflow in arp_req_get().
|
|
|
|
syzkaller reported an overflown write in arp_req_get(). [0]
|
|
|
|
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
|
|
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
|
|
|
|
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
|
|
the sa_data buffer is just 14 bytes.
|
|
|
|
In the splat below, 2 bytes are overflown to the next int field,
|
|
arp_flags. We initialise the field just after the memcpy(), so it's
|
|
not a problem.
|
|
|
|
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
|
|
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
|
|
in arp_ioctl() before calling arp_req_get().
|
|
|
|
To avoid the overflow, let's limit the max length of memcpy().
|
|
|
|
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
|
|
array in struct sockaddr") just silenced syzkaller.
|
|
|
|
[0]:
|
|
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
|
|
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Modules linked in:
|
|
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
|
|
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
|
|
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
|
|
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
|
|
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
|
|
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
|
|
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
|
|
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
|
|
sock_ioctl+0x3ef/0x650 net/socket.c:1321
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:870 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:856 [inline]
|
|
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
|
|
entry_SYSCALL_64_after_hwframe+0x64/0xce
|
|
RIP: 0033:0x7f172b262b8d
|
|
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
|
|
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
|
|
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
|
|
</TASK>(CVE-2024-26733)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix possible use-after-free and null-ptr-deref
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.(CVE-2024-26735)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: don't override retval if we already lost the skb
|
|
|
|
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
|
|
yet, we need to tell the core to drop the skb by setting the retcode
|
|
to SHOT. If we have called tcf_mirred_forward(), however, the skb
|
|
is out of our hands and returning SHOT will lead to UaF.
|
|
|
|
Move the retval override to the error path which actually need it.(CVE-2024-26739)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: use the backlog for mirred ingress
|
|
|
|
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
|
|
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
|
|
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
|
|
lockdep.
|
|
|
|
The problem as previously described by Davide (see Link) is that
|
|
if we reverse flow of traffic with the redirect (egress -> ingress)
|
|
we may reach the same socket which generated the packet. And we may
|
|
still be holding its socket lock. The common solution to such deadlocks
|
|
is to put the packet in the Rx backlog, rather than run the Rx path
|
|
inline. Do that for all egress -> ingress reversals, not just once
|
|
we started to nest mirred calls.
|
|
|
|
In the past there was a concern that the backlog indirection will
|
|
lead to loss of error reporting / less accurate stats. But the current
|
|
workaround does not seem to address the issue.(CVE-2024-26740)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/qedr: Fix qedr_create_user_qp error flow
|
|
|
|
Avoid the following warning by making sure to free the allocated
|
|
resources in case that qedr_init_user_queue() fail.
|
|
|
|
-----------[ cut here ]-----------
|
|
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
|
|
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
|
|
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
|
|
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
|
|
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
|
|
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
|
|
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
|
|
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
|
|
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
|
|
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
|
|
Call Trace:
|
|
<TASK>
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? __warn+0x81/0x110
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? report_bug+0x10a/0x140
|
|
? handle_bug+0x3c/0x70
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
__fput+0x94/0x250
|
|
task_work_run+0x5c/0x90
|
|
do_exit+0x270/0x4a0
|
|
do_group_exit+0x2d/0x90
|
|
get_signal+0x87c/0x8c0
|
|
arch_do_signal_or_restart+0x25/0x100
|
|
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
|
|
exit_to_user_mode_loop+0x9c/0x130
|
|
exit_to_user_mode_prepare+0xb6/0x100
|
|
syscall_exit_to_user_mode+0x12/0x40
|
|
do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? common_interrupt+0x43/0xa0
|
|
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
|
RIP: 0033:0x1470abe3ec6b
|
|
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
|
|
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
|
|
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
|
|
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
|
|
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
|
|
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
|
|
</TASK>
|
|
--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Support specifying the srpt_service_guid parameter
|
|
|
|
Make loading ib_srpt with this parameter set work. The current behavior is
|
|
that setting that parameter while loading the ib_srpt kernel module
|
|
triggers the following kernel crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
Call Trace:
|
|
<TASK>
|
|
parse_one+0x18c/0x1d0
|
|
parse_args+0xe1/0x230
|
|
load_module+0x8de/0xa60
|
|
init_module_from_file+0x8b/0xd0
|
|
idempotent_init_module+0x181/0x240
|
|
__x64_sys_finit_module+0x5a/0xb0
|
|
do_syscall_64+0x5f/0xe0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
l2tp: pass correct message length to ip6_append_data
|
|
|
|
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
|
|
twice when splicing more data into an already partially-occupied skbuff.
|
|
|
|
To manage this, we check whether the skbuff contains data using
|
|
skb_queue_empty when deciding how much data to append using
|
|
ip6_append_data.
|
|
|
|
However, the code which performed the calculation was incorrect:
|
|
|
|
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
|
|
|
|
...due to C operator precedence, this ends up setting ulen to
|
|
transhdrlen for messages with a non-zero length, which results in
|
|
corrupted packets on the wire.
|
|
|
|
Add parentheses to correct the calculation in line with the original
|
|
intent.(CVE-2024-26752)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
|
|
|
|
The gtp_net_ops pernet operations structure for the subsystem must be
|
|
registered before registering the generic netlink family.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
general protection fault, probably for non-canonical address
|
|
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
|
|
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
|
|
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
|
|
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
|
|
RSP: 0018:ffff888014107220 EFLAGS: 00010202
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
|
|
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
|
|
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x90/0xa0
|
|
? die_addr+0x50/0xd0
|
|
? exc_general_protection+0x148/0x220
|
|
? asm_exc_general_protection+0x22/0x30
|
|
? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
? __alloc_skb+0x1dd/0x350
|
|
? __pfx___alloc_skb+0x10/0x10
|
|
genl_dumpit+0x11d/0x230
|
|
netlink_dump+0x5b9/0xce0
|
|
? lockdep_hardirqs_on_prepare+0x253/0x430
|
|
? __pfx_netlink_dump+0x10/0x10
|
|
? kasan_save_track+0x10/0x40
|
|
? __kasan_kmalloc+0x9b/0xa0
|
|
? genl_start+0x675/0x970
|
|
__netlink_dump_start+0x6fc/0x9f0
|
|
genl_family_rcv_msg_dumpit+0x1bb/0x2d0
|
|
? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
|
|
? genl_op_from_small+0x2a/0x440
|
|
? cap_capable+0x1d0/0x240
|
|
? __pfx_genl_start+0x10/0x10
|
|
? __pfx_genl_dumpit+0x10/0x10
|
|
? __pfx_genl_done+0x10/0x10
|
|
? security_capable+0x9d/0xe0(CVE-2024-26754)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm-crypt: don't modify the data when using authenticated encryption
|
|
|
|
It was said that authenticated encryption could produce invalid tag when
|
|
the data that is being encrypted is modified [1]. So, fix this problem by
|
|
copying the data into the clone bio first and then encrypt them inside the
|
|
clone bio.
|
|
|
|
This may reduce performance, but it is needed to prevent the user from
|
|
corrupting the device by writing data with O_DIRECT and modifying them at
|
|
the same time.
|
|
|
|
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).(CVE-2024-26791)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
|
|
|
|
The gtp_link_ops operations structure for the subsystem must be
|
|
registered after registering the gtp_net_ops pernet operations structure.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
[ 1010.702740] gtp: GTP module unloaded
|
|
[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
|
|
[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
|
|
[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1
|
|
[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]
|
|
[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00
|
|
[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203
|
|
[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000
|
|
[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282
|
|
[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000
|
|
[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80
|
|
[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400
|
|
[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000
|
|
[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0
|
|
[ 1010.715968] PKRU: 55555554
|
|
[ 1010.715972] Call Trace:
|
|
[ 1010.715985] ? __die_body.cold+0x1a/0x1f
|
|
[ 1010.715995] ? die_addr+0x43/0x70
|
|
[ 1010.716002] ? exc_general_protection+0x199/0x2f0
|
|
[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30
|
|
[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]
|
|
[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]
|
|
[ 1010.716042] __rtnl_newlink+0x1063/0x1700
|
|
[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0
|
|
[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0
|
|
[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0
|
|
[ 1010.716076] ? __kernel_text_address+0x56/0xa0
|
|
[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0
|
|
[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30
|
|
[ 1010.716098] ? arch_stack_walk+0x9e/0xf0
|
|
[ 1010.716106] ? stack_trace_save+0x91/0xd0
|
|
[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170
|
|
[ 1010.716121] ? __lock_acquire+0x15c5/0x5380
|
|
[ 1010.716139] ? mark_held_locks+0x9e/0xe0
|
|
[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0
|
|
[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700
|
|
[ 1010.716160] rtnl_newlink+0x69/0xa0
|
|
[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50
|
|
[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0
|
|
[ 1010.716179] ? lock_acquire+0x1fe/0x560
|
|
[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50
|
|
[ 1010.716196] netlink_rcv_skb+0x14d/0x440
|
|
[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0
|
|
[ 1010.716208] ? netlink_ack+0xab0/0xab0
|
|
[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50
|
|
[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50
|
|
[ 1010.716226] ? __virt_addr_valid+0x30b/0x590
|
|
[ 1010.716233] netlink_unicast+0x54b/0x800
|
|
[ 1010.716240] ? netlink_attachskb+0x870/0x870
|
|
[ 1010.716248] ? __check_object_size+0x2de/0x3b0
|
|
[ 1010.716254] netlink_sendmsg+0x938/0xe40
|
|
[ 1010.716261] ? netlink_unicast+0x800/0x800
|
|
[ 1010.716269] ? __import_iovec+0x292/0x510
|
|
[ 1010.716276] ? netlink_unicast+0x800/0x800
|
|
[ 1010.716284] __sock_sendmsg+0x159/0x190
|
|
[ 1010.716290] ____sys_sendmsg+0x712/0x880
|
|
[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0
|
|
[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270
|
|
[ 1010.716309] ? lock_acquire+0x1fe/0x560
|
|
[ 1010.716315] ? drain_array_locked+0x90/0x90
|
|
[ 1010.716324] ___sys_sendmsg+0xf8/0x170
|
|
[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170
|
|
[ 1010.716337] ? lockdep_init_map
|
|
---truncated---(CVE-2024-26793)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Avoid potential use-after-free in hci_error_reset
|
|
|
|
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
|
|
BT controller is not responding, the GPIO reset mechanism would
|
|
free the hci_dev and lead to a use-after-free in hci_error_reset.
|
|
|
|
Here's the call trace observed on a ChromeOS device with Intel AX201:
|
|
queue_work_on+0x3e/0x6c
|
|
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
|
|
? init_wait_entry+0x31/0x31
|
|
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
|
|
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
|
|
process_one_work+0x1d8/0x33f
|
|
worker_thread+0x21b/0x373
|
|
kthread+0x13a/0x152
|
|
? pr_cont_work+0x54/0x54
|
|
? kthread_blkcg+0x31/0x31
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This patch holds the reference count on the hci_dev while processing
|
|
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ip_tunnel: prevent perpetual headroom growth
|
|
|
|
syzkaller triggered following kasan splat:
|
|
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
|
|
[..]
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:588
|
|
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
|
|
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
|
|
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
|
|
skb_get_hash include/linux/skbuff.h:1556 [inline]
|
|
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
|
|
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
|
|
...
|
|
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
|
|
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
|
|
..
|
|
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
|
|
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
|
|
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
|
|
...
|
|
|
|
The splat occurs because skb->data points past skb->head allocated area.
|
|
This is because neigh layer does:
|
|
__skb_pull(skb, skb_network_offset(skb));
|
|
|
|
... but skb_network_offset() returns a negative offset and __skb_pull()
|
|
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
|
|
|
|
The negative value is returned because skb->head and skb->data distance is
|
|
more than 64k and skb->network_header (u16) has wrapped around.
|
|
|
|
The bug is in the ip_tunnel infrastructure, which can cause
|
|
dev->needed_headroom to increment ad infinitum.
|
|
|
|
The syzkaller reproducer consists of packets getting routed via a gre
|
|
tunnel, and route of gre encapsulated packets pointing at another (ipip)
|
|
tunnel. The ipip encapsulation finds gre0 as next output device.
|
|
|
|
This results in the following pattern:
|
|
|
|
1). First packet is to be sent out via gre0.
|
|
Route lookup found an output device, ipip0.
|
|
|
|
2).
|
|
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
|
|
output device, rt.dev->needed_headroom (ipip0).
|
|
|
|
3).
|
|
ip output / start_xmit moves skb on to ipip0. which runs the same
|
|
code path again (xmit recursion).
|
|
|
|
4).
|
|
Routing step for the post-gre0-encap packet finds gre0 as output device
|
|
to use for ipip0 encapsulated packet.
|
|
|
|
tunl0->needed_headroom is then incremented based on the (already bumped)
|
|
gre0 device headroom.
|
|
|
|
This repeats for every future packet:
|
|
|
|
gre0->needed_headroom gets inflated because previous packets' ipip0 step
|
|
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
|
|
needed_headroom was increased.
|
|
|
|
For each subsequent packet, gre/ipip0->needed_headroom grows until
|
|
post-expand-head reallocations result in a skb->head/data distance of
|
|
more than 64k.
|
|
|
|
Once that happens, skb->network_header (u16) wraps around when
|
|
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
|
|
after the headroom expansion/reallocation.
|
|
|
|
After this skb_network_offset(skb) returns a different (and negative)
|
|
result post headroom expansion.
|
|
|
|
The next trip to neigh layer (or anything else that would __skb_pull the
|
|
network header) makes skb->data point to a memory location outside
|
|
skb->head area.
|
|
|
|
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
|
|
prevent perpetual increase instead of dropping the headroom increment
|
|
completely.(CVE-2024-26804)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
|
|
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
|
|
size is specified as `len` and passed to skb_put_data(). This `len`
|
|
is based on `skb->end` that is not data offset but buffer offset. The
|
|
`skb->end` contains data and tailroom. Since the tailroom is not
|
|
initialized when the new `skb` created, KMSAN detects uninitialized
|
|
memory area when copying the data.
|
|
|
|
This patch resolved this issue by correct the len from `skb->end` to
|
|
`skb->len`, which is the actual data offset.
|
|
|
|
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
copy_to_iter include/linux/uio.h:197 [inline]
|
|
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
|
|
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
|
|
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
|
|
sock_recvmsg_nosec net/socket.c:1044 [inline]
|
|
sock_recvmsg net/socket.c:1066 [inline]
|
|
sock_read_iter+0x467/0x580 net/socket.c:1136
|
|
call_read_iter include/linux/fs.h:2014 [inline]
|
|
new_sync_read fs/read_write.c:389 [inline]
|
|
vfs_read+0x8f6/0xe00 fs/read_write.c:470
|
|
ksys_read+0x20f/0x4c0 fs/read_write.c:613
|
|
__do_sys_read fs/read_write.c:623 [inline]
|
|
__se_sys_read fs/read_write.c:621 [inline]
|
|
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was stored to memory at:
|
|
skb_put_data include/linux/skbuff.h:2622 [inline]
|
|
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
|
|
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
|
|
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
|
|
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
|
|
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
free_pages_prepare mm/page_alloc.c:1087 [inline]
|
|
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
|
|
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
|
|
release_pages+0x23d3/0x2410 mm/swap.c:1042
|
|
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
|
|
tlb_batch_pages
|
|
---truncated---(CVE-2024-26805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/platform: Create persistent IRQ handlers
|
|
|
|
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
|
|
an interrupt before a signaling eventfd has been configured by the user,
|
|
which thereby allows a NULL pointer dereference.
|
|
|
|
Rather than register the IRQ relative to a valid trigger, register all
|
|
IRQs in a disabled state in the device open path. This allows mask
|
|
operations on the IRQ to nest within the overall enable state governed
|
|
by a valid eventfd signal. This decouples @masked, protected by the
|
|
@locked spinlock from @trigger, protected via the @igate mutex.
|
|
|
|
In doing so, it's guaranteed that changes to @trigger cannot race the
|
|
IRQ handlers because the IRQ handler is synchronously disabled before
|
|
modifying the trigger, and loopback triggering of the IRQ via ioctl is
|
|
safe due to serialization with trigger changes via igate.
|
|
|
|
For compatibility, request_irq() failures are maintained to be local to
|
|
the SET_IRQS ioctl rather than a fatal error in the open device path.
|
|
This allows, for example, a userspace driver with polling mode support
|
|
to continue to work regardless of moving the request_irq() call site.
|
|
This necessarily blocks all SET_IRQS access to the failed index.(CVE-2024-26813)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.(CVE-2024-26817)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.(CVE-2024-26828)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.(CVE-2024-26839)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.(CVE-2024-26840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-fc: do not wait in vain when unloading module
|
|
|
|
The module exit path has race between deleting all controllers and
|
|
freeing 'left over IDs'. To prevent double free a synchronization
|
|
between nvme_delete_ctrl and ida_destroy has been added by the initial
|
|
commit.
|
|
|
|
There is some logic around trying to prevent from hanging forever in
|
|
wait_for_completion, though it does not handling all cases. E.g.
|
|
blktests is able to reproduce the situation where the module unload
|
|
hangs forever.
|
|
|
|
If we completely rely on the cleanup code executed from the
|
|
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
|
|
calling ida_destroy unnecessary. We only have to ensure that all
|
|
nvme_delete_ctrl code has been executed before we leave
|
|
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
|
|
workqueue.
|
|
|
|
While at it, remove the unused nvme_fc_wq workqueue too.(CVE-2024-26846)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---(CVE-2024-26852)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
geneve: make sure to pull inner header in geneve_rx()
|
|
|
|
syzbot triggered a bug in geneve_rx() [1]
|
|
|
|
Issue is similar to the one I fixed in commit 8d975c15c0cd
|
|
("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
|
|
|
|
We have to save skb->network_header in a temporary variable
|
|
in order to be able to recompute the network_header pointer
|
|
after a pskb_inet_may_pull() call.
|
|
|
|
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
|
|
IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
|
|
geneve_rx drivers/net/geneve.c:279 [inline]
|
|
geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
|
|
udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
|
|
udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
|
|
udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
|
|
__udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
|
|
udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
|
|
ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
|
|
ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
|
|
__netif_receive_skb_one_core net/core/dev.c:5534 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
|
|
process_backlog+0x480/0x8b0 net/core/dev.c:5976
|
|
__napi_poll+0xe3/0x980 net/core/dev.c:6576
|
|
napi_poll net/core/dev.c:6645 [inline]
|
|
net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
|
|
__do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
|
|
do_softirq+0x9a/0xf0 kernel/softirq.c:454
|
|
__local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
|
|
local_bh_enable include/linux/bottom_half.h:33 [inline]
|
|
rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
|
|
__dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
|
|
dev_queue_xmit include/linux/netdevice.h:3171 [inline]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3081 [inline]
|
|
packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slub.c:3819 [inline]
|
|
slab_alloc_node mm/slub.c:3860 [inline]
|
|
kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x352/0x790 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1296 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
|
|
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
|
|
packet_snd net/packet/af_packet.c:3024 [inline]
|
|
packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/bnx2x: Prevent access to a freed page in page_pool
|
|
|
|
Fix race condition leading to system crash during EEH error handling
|
|
|
|
During EEH error recovery, the bnx2x driver's transmit timeout logic
|
|
could cause a race condition when handling reset tasks. The
|
|
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
|
|
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
|
|
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
|
|
overlap with the EEH driver's attempt to reset the device using
|
|
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
|
|
condition can result in system crashes due to accessing freed memory
|
|
locations in bnx2x_free_rx_sge()
|
|
|
|
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
|
|
800 struct bnx2x_fastpath *fp, u16 index)
|
|
801 {
|
|
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
|
|
803 struct page *page = sw_buf->page;
|
|
....
|
|
where sw_buf was set to NULL after the call to dma_unmap_page()
|
|
by the preceding thread.
|
|
|
|
EEH: Beginning: 'slot_reset'
|
|
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
|
|
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
|
|
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
|
|
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
|
|
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
|
|
BUG: Kernel NULL pointer dereference on read at 0x00000000
|
|
Faulting instruction address: 0xc0080000025065fc
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
.....
|
|
Call Trace:
|
|
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
|
|
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
|
|
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
|
|
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
|
|
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
|
|
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
|
|
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
|
|
|
|
To solve this issue, we need to verify page pool allocations before
|
|
freeing.(CVE-2024-26859)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hsr: Fix uninit-value access in hsr_get_node()
|
|
|
|
KMSAN reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
|
|
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
|
|
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3087 [inline]
|
|
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
|
|
packet_snd net/packet/af_packet.c:3030 [inline]
|
|
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
=====================================================
|
|
|
|
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
|
|
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
|
|
reads an invalid value as a sequence number. This causes the above issue.
|
|
|
|
This patch fixes the issue by returning NULL if the Ethernet header is not
|
|
followed by an HSR tag.(CVE-2024-26863)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Do not register event handler until srpt device is fully setup
|
|
|
|
Upon rare occasions, KASAN reports a use-after-free Write
|
|
in srpt_refresh_port().
|
|
|
|
This seems to be because an event handler is registered before the
|
|
srpt device is fully setup and a race condition upon error may leave a
|
|
partially setup event handler in place.
|
|
|
|
Instead, only register the event handler after srpt device initialization
|
|
is complete.(CVE-2024-26872)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.(CVE-2024-26875)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: adv7511: fix crash on irq during probe
|
|
|
|
Moved IRQ registration down to end of adv7511_probe().
|
|
|
|
If an IRQ already is pending during adv7511_probe
|
|
(before adv7511_cec_init) then cec_received_msg_ts
|
|
could crash using uninitialized data:
|
|
|
|
Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
|
|
Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
|
|
Call trace:
|
|
cec_received_msg_ts+0x48/0x990 [cec]
|
|
adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
|
|
adv7511_irq_process+0xd8/0x120 [adv7511]
|
|
adv7511_irq_handler+0x1c/0x30 [adv7511]
|
|
irq_thread_fn+0x30/0xa0
|
|
irq_thread+0x14c/0x238
|
|
kthread+0x190/0x1a8(CVE-2024-26876)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm: call the resume method on internal suspend
|
|
|
|
There is this reported crash when experimenting with the lvm2 testsuite.
|
|
The list corruption is caused by the fact that the postsuspend and resume
|
|
methods were not paired correctly; there were two consecutive calls to the
|
|
origin_postsuspend function. The second call attempts to remove the
|
|
"hash_list" entry from a list, while it was already removed by the first
|
|
call.
|
|
|
|
Fix __dm_internal_resume so that it calls the preresume and resume
|
|
methods of the table's targets.
|
|
|
|
If a preresume method of some target fails, we are in a tricky situation.
|
|
We can't return an error because dm_internal_resume isn't supposed to
|
|
return errors. We can't return success, because then the "resume" and
|
|
"postsuspend" methods would not be paired correctly. So, we set the
|
|
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
|
|
tools, but it won't cause a kernel crash.
|
|
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/list_debug.c:56!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
|
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
|
|
<snip>
|
|
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
|
|
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
|
|
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
|
|
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
|
|
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
|
|
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
|
|
FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
|
|
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x2d/0x80
|
|
? do_trap+0xeb/0xf0
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? do_error_trap+0x60/0x80
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? exc_invalid_op+0x49/0x60
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
origin_postsuspend+0x1a/0x50 [dm_snapshot]
|
|
dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
|
|
dm_suspend+0xd8/0xf0 [dm_mod]
|
|
dev_suspend+0x1f2/0x2f0 [dm_mod]
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
ctl_ioctl+0x300/0x5f0 [dm_mod]
|
|
dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
|
|
__x64_compat_sys_ioctl+0x104/0x170
|
|
do_syscall_64+0x184/0x1b0
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0xf7e6aead
|
|
<snip>
|
|
---[ end trace 0000000000000000 ]---(CVE-2024-26880)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
|
|
|
|
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
|
|
structures have been fully initialised by the time it runs. However, because of
|
|
the order in which things are initialised, this is not guaranteed to be the
|
|
case, because the device is exposed to the USB subsystem before the ath9k driver
|
|
initialisation is completed.
|
|
|
|
We already committed a partial fix for this in commit:
|
|
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
|
|
|
|
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
|
|
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
|
|
seems syzbot managed to trigger the race for one of the other commands as well,
|
|
so let's just move the existing synchronisation bit to cover the whole
|
|
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
|
|
ath9k_tx_init()).(CVE-2024-26897)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
|
|
|
|
This patch is against CVE-2023-6270. The description of cve is:
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
|
|
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
|
|
`struct net_device`, and a use-after-free can be triggered by racing
|
|
between the free on the struct and the access through the `skbtxq`
|
|
global queue. This could lead to a denial of service condition or
|
|
potential code execution.
|
|
|
|
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
|
|
code is finished. But the net_device ifp will still be used in
|
|
later tx()->dev_queue_xmit() in kthread. Which means that the
|
|
dev_put(ifp) should NOT be called in the success path of skb
|
|
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
|
|
use-after-free because the net_device is freed.
|
|
|
|
This patch removed the dev_put(ifp) in the success path in
|
|
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().(CVE-2024-26898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Reset IH OVERFLOW_CLEAR bit
|
|
|
|
Allows us to detect subsequent IH ring buffer overflows as well.(CVE-2024-26915)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: validate the parameters of bo mapping operations more clearly
|
|
|
|
Verify the parameters of
|
|
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.(CVE-2024-26922)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: go7007: fix a memleak in go7007_load_encoder
|
|
|
|
In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
|
|
a deallocation thereafter. After the following call chain:
|
|
|
|
saa7134_go7007_init
|
|
|-> go7007_boot_encoder
|
|
|-> go7007_load_encoder
|
|
|-> kfree(go)
|
|
|
|
go is freed and thus bounce is leaked.(CVE-2024-27074)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47082</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47110</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47184</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48674</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52615</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52620</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52623</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52629</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52635</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52637</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52638</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52639</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52642</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52644</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-6270</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24858</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26614</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26642</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26645</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26668</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26671</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26675</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26679</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26685</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26686</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26697</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26720</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26726</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26733</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26735</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26739</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26740</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26743</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26744</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26752</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26754</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26763</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26791</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26793</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26801</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26804</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26812</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26813</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26817</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26828</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26839</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26846</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26852</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26857</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26859</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26863</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26872</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26875</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26876</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26878</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26880</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26897</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26915</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26922</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27074</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47082</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47110</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47184</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48674</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52615</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52620</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52623</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52629</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52635</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52637</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52638</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52639</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52642</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52644</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-6270</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24858</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26614</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26642</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26645</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26668</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26671</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26675</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26679</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26686</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26697</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26720</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26726</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26733</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26735</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26739</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26740</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26743</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26744</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26752</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26754</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26763</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26793</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26801</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26804</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26812</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26813</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26828</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26839</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26846</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26852</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26857</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26859</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26863</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26872</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26875</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26876</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26878</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26880</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26897</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26915</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26922</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27074</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.3.0.0276.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.3.0.0276.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.3.0.0276" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.3.0.0276.oe2003sp4.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:
|
|
|
|
tun: avoid double free in tun_free_netdev
|
|
|
|
Avoid double free in tun_free_netdev() by moving the
|
|
dev->tstats and tun->security allocs to a new ndo_init routine
|
|
(tun_net_init()) that will be called by register_netdevice().
|
|
ndo_init is paired with the desctructor (tun_free_netdev()),
|
|
so if there's an error in register_netdevice() the destructor
|
|
will handle the frees.
|
|
|
|
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
|
|
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
|
|
Hardware name: Red Hat KVM, BIOS
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
|
|
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
|
|
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
|
|
____kasan_slab_free mm/kasan/common.c:346 [inline]
|
|
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
|
|
kasan_slab_free include/linux/kasan.h:235 [inline]
|
|
slab_free_hook mm/slub.c:1723 [inline]
|
|
slab_free_freelist_hook mm/slub.c:1749 [inline]
|
|
slab_free mm/slub.c:3513 [inline]
|
|
kfree+0xac/0x2d0 mm/slub.c:4561
|
|
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
|
|
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
|
|
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
|
|
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
|
|
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
|
|
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:874 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:860 [inline]
|
|
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2021-47082</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/kvm: Disable kvmclock on all CPUs on shutdown
|
|
|
|
Currenly, we disable kvmclock from machine_shutdown() hook and this
|
|
only happens for boot CPU. We need to disable it for all CPUs to
|
|
guard against memory corruption e.g. on restore from hibernate.
|
|
|
|
Note, writing '0' to kvmclock MSR doesn't clear memory location, it
|
|
just prevents hypervisor from updating the location so for the short
|
|
while after write and while CPU is still alive, the clock remains usable
|
|
and correct so we don't need to switch to some other clocksource.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2021-47110</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Fix NULL ptr dereference on VSI filter sync
|
|
|
|
Remove the reason of null pointer dereference in sync VSI filters.
|
|
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
|
|
of VSI resources to sync this thread with sync filters subtask.
|
|
Without this patch it is possible to start update the VSI filter list
|
|
after VSI is removed, that's causing a kernel oops.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2021-47184</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
erofs: fix pcluster use-after-free on UP platforms
|
|
|
|
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
|
|
Read of size 8 at addr ffff8881094223f8 by task stress/7789
|
|
|
|
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
Call Trace:
|
|
<TASK>
|
|
..
|
|
__mutex_lock+0xe5/0xc30
|
|
..
|
|
z_erofs_do_read_page+0x8ce/0x1560
|
|
..
|
|
z_erofs_readahead+0x31c/0x580
|
|
..
|
|
Freed by task 7787
|
|
kasan_save_stack+0x1e/0x40
|
|
kasan_set_track+0x20/0x30
|
|
kasan_set_free_info+0x20/0x40
|
|
__kasan_slab_free+0x10c/0x190
|
|
kmem_cache_free+0xed/0x380
|
|
rcu_core+0x3d5/0xc90
|
|
__do_softirq+0x12d/0x389
|
|
|
|
Last potentially related work creation:
|
|
kasan_save_stack+0x1e/0x40
|
|
__kasan_record_aux_stack+0x97/0xb0
|
|
call_rcu+0x3d/0x3f0
|
|
erofs_shrink_workstation+0x11f/0x210
|
|
erofs_shrink_scan+0xdc/0x170
|
|
shrink_slab.constprop.0+0x296/0x530
|
|
drop_slab+0x1c/0x70
|
|
drop_caches_sysctl_handler+0x70/0x80
|
|
proc_sys_call_handler+0x20a/0x2f0
|
|
vfs_write+0x555/0x6c0
|
|
ksys_write+0xbe/0x160
|
|
do_syscall_64+0x3b/0x90
|
|
|
|
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
|
|
orig_val thus it causes a race that the pcluster reuses unexpectedly
|
|
before freeing.
|
|
|
|
Since UP platforms are quite rare now, such path becomes unnecessary.
|
|
Let's drop such specific-designed path directly instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2022-48674</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
|
|
|
|
There is a dead-lock in the hwrng device read path. This triggers
|
|
when the user reads from /dev/hwrng into memory also mmap-ed from
|
|
/dev/hwrng. The resulting page fault triggers a recursive read
|
|
which then dead-locks.
|
|
|
|
Fix this by using a stack buffer when calling copy_to_user.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52615</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52620</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: Fix a suspicious RCU usage warning
|
|
|
|
I received the following warning while running cthon against an ontap
|
|
server running pNFS:
|
|
|
|
[ 57.202521] =============================
|
|
[ 57.202522] WARNING: suspicious RCU usage
|
|
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
|
|
[ 57.202525] -----------------------------
|
|
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
|
|
[ 57.202527]
|
|
other info that might help us debug this:
|
|
|
|
[ 57.202528]
|
|
rcu_scheduler_active = 2, debug_locks = 1
|
|
[ 57.202529] no locks held by test5/3567.
|
|
[ 57.202530]
|
|
stack backtrace:
|
|
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
|
|
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
|
|
[ 57.202536] Call Trace:
|
|
[ 57.202537] <TASK>
|
|
[ 57.202540] dump_stack_lvl+0x77/0xb0
|
|
[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0
|
|
[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
|
|
[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
|
|
[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
|
|
[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202866] write_cache_pages+0x265/0x450
|
|
[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202913] do_writepages+0xd2/0x230
|
|
[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80
|
|
[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80
|
|
[ 57.202924] filemap_write_and_wait_range+0xd9/0x170
|
|
[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
|
|
[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
|
|
[ 57.202969] __se_sys_close+0x46/0xd0
|
|
[ 57.202972] do_syscall_64+0x68/0x100
|
|
[ 57.202975] ? do_syscall_64+0x77/0x100
|
|
[ 57.202976] ? do_syscall_64+0x77/0x100
|
|
[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
[ 57.202982] RIP: 0033:0x7fe2b12e4a94
|
|
[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
|
|
[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
|
|
[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
|
|
[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
|
|
[ 57.202993] R10: 00007f
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52623</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
|
|
|
|
The original code puts flush_work() before timer_shutdown_sync()
|
|
in switch_drv_remove(). Although we use flush_work() to stop
|
|
the worker, it could be rescheduled in switch_timer(). As a result,
|
|
a use-after-free bug can occur. The details are shown below:
|
|
|
|
(cpu 0) | (cpu 1)
|
|
switch_drv_remove() |
|
|
flush_work() |
|
|
... | switch_timer // timer
|
|
| schedule_work(&psw->work)
|
|
timer_shutdown_sync() |
|
|
... | switch_work_handler // worker
|
|
kfree(psw) // free |
|
|
| psw->state = 0 // use
|
|
|
|
This patch puts timer_shutdown_sync() before flush_work() to
|
|
mitigate the bugs. As a result, the worker and timer will be
|
|
stopped safely before the deallocate operations.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52629</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
|
|
|
|
There is a chance if a frequent switch of the governor
|
|
done in a loop result in timer list corruption where
|
|
timer cancel being done from two place one from
|
|
cancel_delayed_work_sync() and followed by expire_timers()
|
|
can be seen from the traces[1].
|
|
|
|
while true
|
|
do
|
|
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
|
|
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
|
|
done
|
|
|
|
It looks to be issue with devfreq driver where
|
|
device_monitor_[start/stop] need to synchronized so that
|
|
delayed work should get corrupted while it is either
|
|
being queued or running or being cancelled.
|
|
|
|
Let's use polling flag and devfreq lock to synchronize the
|
|
queueing the timer instance twice and work data being
|
|
corrupted.
|
|
|
|
[1]
|
|
...
|
|
..
|
|
<idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
|
|
<idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
|
|
<idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
|
|
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
|
|
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
|
|
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
|
|
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
|
|
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
|
|
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
|
|
|
|
[2]
|
|
|
|
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
|
|
[ 9436.261664][ C4] Mem abort info:
|
|
[ 9436.261666][ C4] ESR = 0x96000044
|
|
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
|
|
[ 9436.261671][ C4] SET = 0, FnV = 0
|
|
[ 9436.261673][ C4] EA = 0, S1PTW = 0
|
|
[ 9436.261675][ C4] Data abort info:
|
|
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
|
|
[ 9436.261680][ C4] CM = 0, WnR = 1
|
|
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
|
|
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
|
|
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
|
|
...
|
|
|
|
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
|
|
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
|
|
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
|
|
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
|
|
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
|
|
[ 9436.262168][ C4] sp : ffffffc010023dd0
|
|
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
|
|
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
|
|
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
|
|
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
|
|
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
|
|
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
|
|
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
|
|
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
|
|
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
|
|
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
|
|
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
|
|
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
|
|
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
|
|
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52635</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
|
|
|
|
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
|
|
modifies jsk->filters while receiving packets.
|
|
|
|
Following trace was seen on affected system:
|
|
==================================================================
|
|
BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
Read of size 4 at addr ffff888012144014 by task j1939/350
|
|
|
|
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
print_report+0xd3/0x620
|
|
? kasan_complete_mode_report_info+0x7d/0x200
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
kasan_report+0xc2/0x100
|
|
? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
__asan_load4+0x84/0xb0
|
|
j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
|
|
j1939_sk_recv+0x20b/0x320 [can_j1939]
|
|
? __kasan_check_write+0x18/0x20
|
|
? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
|
|
? j1939_simple_recv+0x69/0x280 [can_j1939]
|
|
? j1939_ac_recv+0x5e/0x310 [can_j1939]
|
|
j1939_can_recv+0x43f/0x580 [can_j1939]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
? raw_rcv+0x42/0x3c0 [can_raw]
|
|
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
|
|
can_rcv_filter+0x11f/0x350 [can]
|
|
can_receive+0x12f/0x190 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
can_rcv+0xdd/0x130 [can]
|
|
? __pfx_can_rcv+0x10/0x10 [can]
|
|
__netif_receive_skb_one_core+0x13d/0x150
|
|
? __pfx___netif_receive_skb_one_core+0x10/0x10
|
|
? __kasan_check_write+0x18/0x20
|
|
? _raw_spin_lock_irq+0x8c/0xe0
|
|
__netif_receive_skb+0x23/0xb0
|
|
process_backlog+0x107/0x260
|
|
__napi_poll+0x69/0x310
|
|
net_rx_action+0x2a1/0x580
|
|
? __pfx_net_rx_action+0x10/0x10
|
|
? __pfx__raw_spin_lock+0x10/0x10
|
|
? handle_irq_event+0x7d/0xa0
|
|
__do_softirq+0xf3/0x3f8
|
|
do_softirq+0x53/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x6e/0x70
|
|
netif_rx+0x16b/0x180
|
|
can_send+0x32b/0x520 [can]
|
|
? __pfx_can_send+0x10/0x10 [can]
|
|
? __check_object_size+0x299/0x410
|
|
raw_sendmsg+0x572/0x6d0 [can_raw]
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
? apparmor_socket_sendmsg+0x2f/0x40
|
|
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
|
|
sock_sendmsg+0xef/0x100
|
|
sock_write_iter+0x162/0x220
|
|
? __pfx_sock_write_iter+0x10/0x10
|
|
? __rtnl_unlock+0x47/0x80
|
|
? security_file_permission+0x54/0x320
|
|
vfs_write+0x6ba/0x750
|
|
? __pfx_vfs_write+0x10/0x10
|
|
? __fget_light+0x1ca/0x1f0
|
|
? __rcu_read_unlock+0x5b/0x280
|
|
ksys_write+0x143/0x170
|
|
? __pfx_ksys_write+0x10/0x10
|
|
? __kasan_check_read+0x15/0x20
|
|
? fpregs_assert_state_consistent+0x62/0x70
|
|
__x64_sys_write+0x47/0x60
|
|
do_syscall_64+0x60/0x90
|
|
? do_syscall_64+0x6d/0x90
|
|
? irqentry_exit+0x3f/0x50
|
|
? exc_page_fault+0x79/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Allocated by task 348:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_alloc_info+0x1f/0x30
|
|
__kasan_kmalloc+0xb5/0xc0
|
|
__kmalloc_node_track_caller+0x67/0x160
|
|
j1939_sk_setsockopt+0x284/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
|
|
Freed by task 349:
|
|
kasan_save_stack+0x2a/0x50
|
|
kasan_set_track+0x29/0x40
|
|
kasan_save_free_info+0x2f/0x50
|
|
__kasan_slab_free+0x12e/0x1c0
|
|
__kmem_cache_free+0x1b9/0x380
|
|
kfree+0x7a/0x120
|
|
j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
|
|
__sys_setsockopt+0x15c/0x2f0
|
|
__x64_sys_setsockopt+0x6b/0x80
|
|
do_syscall_64+0x60/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52637</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="11" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
|
|
|
|
The following 3 locks would race against each other, causing the
|
|
deadlock situation in the Syzbot bug report:
|
|
|
|
- j1939_socks_lock
|
|
- active_session_list_lock
|
|
- sk_session_queue_lock
|
|
|
|
A reasonable fix is to change j1939_socks_lock to an rwlock, since in
|
|
the rare situations where a write lock is required for the linked list
|
|
that j1939_socks_lock is protecting, the code does not attempt to
|
|
acquire any more locks. This would break the circular lock dependency,
|
|
where, for example, the current thread already locks j1939_socks_lock
|
|
and attempts to acquire sk_session_queue_lock, and at the same time,
|
|
another thread attempts to acquire j1939_socks_lock while holding
|
|
sk_session_queue_lock.
|
|
|
|
NOTE: This patch along does not fix the unregister_netdevice bug
|
|
reported by Syzbot; instead, it solves a deadlock situation to prepare
|
|
for one or more further patches to actually fix the Syzbot bug, which
|
|
appears to be a reference counting problem within the j1939 codebase.
|
|
|
|
[mkl: remove unrelated newline change]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52638</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: s390: vsie: fix race during shadow creation
|
|
|
|
Right now it is possible to see gmap->private being zero in
|
|
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
|
|
fact that we add gmap->private == kvm after creation:
|
|
|
|
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
|
|
struct vsie_page *vsie_page)
|
|
{
|
|
[...]
|
|
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
|
|
if (IS_ERR(gmap))
|
|
return PTR_ERR(gmap);
|
|
gmap->private = vcpu->kvm;
|
|
|
|
Let children inherit the private field of the parent.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52639</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52642</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
|
|
|
|
When QoS is disabled, the queue priority value will not map to the correct
|
|
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
|
|
is disabled to prevent trying to stop/wake a non-existent queue and failing
|
|
to stop/wake the actual queue instantiated.
|
|
|
|
Log of issue before change (with kernel parameter qos=0):
|
|
[ +5.112651] ------------[ cut here ]------------
|
|
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
|
|
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
|
|
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
|
|
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
|
|
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
|
|
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
|
|
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
|
|
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
|
|
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
|
|
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
|
|
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
|
|
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
|
|
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
|
|
[ +0.000001] CS: 0010 DS: 0
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52644</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-6270</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" xml:lang="en">A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
|
|
|
|
|
|
|
|
|
|
</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-24858</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: make sure init the accept_queue's spinlocks once
|
|
|
|
When I run syz's reproduction C program locally, it causes the following
|
|
issue:
|
|
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
|
|
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
|
|
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
|
|
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
|
|
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
|
|
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
|
|
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
|
|
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
|
|
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
|
|
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<IRQ>
|
|
_raw_spin_unlock (kernel/locking/spinlock.c:186)
|
|
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
|
|
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
|
|
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
|
|
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
|
|
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
|
|
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
|
|
__netif_receive_skb_one_core (net/core/dev.c:5529)
|
|
process_backlog (./include/linux/rcupdate.h:779)
|
|
__napi_poll (net/core/dev.c:6533)
|
|
net_rx_action (net/core/dev.c:6604)
|
|
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
|
|
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip (kernel/softirq.c:381)
|
|
__dev_queue_xmit (net/core/dev.c:4374)
|
|
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
|
|
__ip_queue_xmit (net/ipv4/ip_output.c:535)
|
|
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
|
|
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
|
|
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
|
|
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
|
|
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
|
|
release_sock (net/core/sock.c:3536)
|
|
inet_wait_for_connect (net/ipv4/af_inet.c:609)
|
|
__inet_stream_connect (net/ipv4/af_inet.c:702)
|
|
inet_stream_connect (net/ipv4/af_inet.c:748)
|
|
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
|
|
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
|
|
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
|
|
RIP: 0033:0x7fa10ff05a3d
|
|
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 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 ab a3 0e 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
|
|
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
|
|
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
|
|
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
|
|
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
|
|
</TASK>
|
|
|
|
The issue triggering process is analyzed as follows:
|
|
Thread A Thread B
|
|
tcp_v4_rcv //receive ack TCP packet inet_shutdown
|
|
tcp_check_req tcp_disconnect //disconnect sock
|
|
... tcp_set_state(sk, TCP_CLOSE)
|
|
inet_csk_complete_hashdance ...
|
|
inet_csk_reqsk_queue_add
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26614</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.9</BaseScore>
|
|
<Vector>AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow anonymous set with timeout flag
|
|
|
|
Anonymous sets are never used with timeout from userspace, reject this.
|
|
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26642</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing: Ensure visibility when inserting an element into tracing_map
|
|
|
|
Running the following two commands in parallel on a multi-processor
|
|
AArch64 machine can sporadically produce an unexpected warning about
|
|
duplicate histogram entries:
|
|
|
|
$ while true; do
|
|
echo hist:key=id.syscall:val=hitcount > \
|
|
/sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
|
|
cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
|
|
sleep 0.001
|
|
done
|
|
$ stress-ng --sysbadaddr $(nproc)
|
|
|
|
The warning looks as follows:
|
|
|
|
[ 2911.172474] ------------[ cut here ]------------
|
|
[ 2911.173111] Duplicates detected: 1
|
|
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
|
|
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
|
|
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
|
|
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
|
|
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.185310] sp : ffff8000a1513900
|
|
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
|
|
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
|
|
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
|
|
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
|
|
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
|
|
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
|
|
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
|
|
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
|
|
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
|
|
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
|
|
[ 2911.194259] Call trace:
|
|
[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408
|
|
[ 2911.195220] hist_show+0x124/0x800
|
|
[ 2911.195692] seq_read_iter+0x1d4/0x4e8
|
|
[ 2911.196193] seq_read+0xe8/0x138
|
|
[ 2911.196638] vfs_read+0xc8/0x300
|
|
[ 2911.197078] ksys_read+0x70/0x108
|
|
[ 2911.197534] __arm64_sys_read+0x24/0x38
|
|
[ 2911.198046] invoke_syscall+0x78/0x108
|
|
[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8
|
|
[ 2911.199157] do_el0_svc+0x28/0x40
|
|
[ 2911.199613] el0_svc+0x40/0x178
|
|
[ 2911.200048] el0t_64_sync_handler+0x13c/0x158
|
|
[ 2911.200621] el0t_64_sync+0x1a8/0x1b0
|
|
[ 2911.201115] ---[ end trace 0000000000000000 ]---
|
|
|
|
The problem appears to be caused by CPU reordering of writes issued from
|
|
__tracing_map_insert().
|
|
|
|
The check for the presence of an element with a given key in this
|
|
function is:
|
|
|
|
val = READ_ONCE(entry->val);
|
|
if (val && keys_match(key, val->key, map->key_size)) ...
|
|
|
|
The write of a new entry is:
|
|
|
|
elt = get_free_elt(map);
|
|
memcpy(elt->key, key, map->key_size);
|
|
entry->val = elt;
|
|
|
|
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
|
|
stores may become visible in the reversed order on another CPU. This
|
|
second CPU might then incorrectly determine that a new key doesn't match
|
|
an already present val->key and subse
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26645</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26668</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26671</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppp_async: limit MRU to 64K
|
|
|
|
syzbot triggered a warning [1] in __alloc_pages():
|
|
|
|
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
|
|
|
|
Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
|
|
|
|
Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
|
|
|
|
[1]:
|
|
|
|
WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
Modules linked in:
|
|
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
Workqueue: events_unbound flush_to_ldisc
|
|
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
|
|
sp : ffff800093967580
|
|
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
|
|
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
|
|
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
|
|
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
|
|
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
|
|
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
|
|
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
|
|
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
|
|
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
|
|
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
|
|
Call trace:
|
|
__alloc_pages+0x308/0x698 mm/page_alloc.c:4543
|
|
__alloc_pages_node include/linux/gfp.h:238 [inline]
|
|
alloc_pages_node include/linux/gfp.h:261 [inline]
|
|
__kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
|
|
__do_kmalloc_node mm/slub.c:3969 [inline]
|
|
__kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
|
|
kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
|
|
__alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
|
|
__netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
|
|
netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
|
|
dev_alloc_skb include/linux/skbuff.h:3248 [inline]
|
|
ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
|
|
ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
|
|
tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
|
|
tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
|
|
receive_buf drivers/tty/tty_buffer.c:444 [inline]
|
|
flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
|
|
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
|
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
|
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
|
kthread+0x288/0x310 kernel/kthread.c:388
|
|
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26675</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet: read sk->sk_family once in inet_recv_error()
|
|
|
|
inet_recv_error() is called without holding the socket lock.
|
|
|
|
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
|
|
socket option and trigger a KCSAN warning.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26679</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential bug in end_buffer_async_write
|
|
|
|
According to a syzbot report, end_buffer_async_write(), which handles the
|
|
completion of block device writes, may detect abnormal condition of the
|
|
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
|
|
|
|
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
|
|
flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
|
|
with race condition of competition between segments for dirty blocks") as
|
|
a means of resolving double list insertion of dirty blocks in
|
|
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
|
|
resulting crash.
|
|
|
|
This modification is safe as long as it is used for file data and b-tree
|
|
node blocks where the page caches are independent. However, it was
|
|
irrelevant and redundant to also introduce async_write for segment summary
|
|
and super root blocks that share buffers with the backing device. This
|
|
led to the possibility that the BUG_ON check in end_buffer_async_write
|
|
would fail as described above, if independent writebacks of the backing
|
|
device occurred in parallel.
|
|
|
|
The use of async_write for segment summary buffers has already been
|
|
removed in a previous change.
|
|
|
|
Fix this issue by removing the manipulation of the async_write flag for
|
|
the remaining super root block buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26685</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
|
|
|
|
lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call
|
|
do_task_stat() at the same time and the process has NR_THREADS, it will
|
|
spin with irqs disabled O(NR_CPUS * NR_THREADS) time.
|
|
|
|
Change do_task_stat() to use sig->stats_lock to gather the statistics
|
|
outside of ->siglock protected section, in the likely case this code will
|
|
run lockless.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26686</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix data corruption in dsync block recovery for small block sizes
|
|
|
|
The helper function nilfs_recovery_copy_block() of
|
|
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
|
|
data sync writes during a mount after an unclean shutdown, incorrectly
|
|
calculates the on-page offset when copying repair data to the file's page
|
|
cache. In environments where the block size is smaller than the page
|
|
size, this flaw can cause data corruption and leak uninitialized memory
|
|
bytes during the recovery process.
|
|
|
|
Fix these issues by correcting this byte offset calculation on the page.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26697</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
|
|
|
|
(struct dirty_throttle_control *)->thresh is an unsigned long, but is
|
|
passed as the u32 divisor argument to div_u64(). On architectures where
|
|
unsigned long is 64 bytes, the argument will be implicitly truncated.
|
|
|
|
Use div64_u64() instead of div_u64() so that the value used in the "is
|
|
this a safe division" check is the same as the divisor.
|
|
|
|
Also, remove redundant cast of the numerator to u64, as that should happen
|
|
implicitly.
|
|
|
|
This would be difficult to exploit in memcg domain, given the ratio-based
|
|
arithmetic domain_drity_limits() uses, but is much easier in global
|
|
writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
|
|
vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26720</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't drop extent_map for free space inode on write error
|
|
|
|
While running the CI for an unrelated change I hit the following panic
|
|
with generic/648 on btrfs_holes_spacecache.
|
|
|
|
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
|
|
------------[ cut here ]------------
|
|
kernel BUG at fs/btrfs/extent_io.c:1385!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1
|
|
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
|
|
Call Trace:
|
|
<TASK>
|
|
extent_write_cache_pages+0x2ac/0x8f0
|
|
extent_writepages+0x87/0x110
|
|
do_writepages+0xd5/0x1f0
|
|
filemap_fdatawrite_wbc+0x63/0x90
|
|
__filemap_fdatawrite_range+0x5c/0x80
|
|
btrfs_fdatawrite_range+0x1f/0x50
|
|
btrfs_write_out_cache+0x507/0x560
|
|
btrfs_write_dirty_block_groups+0x32a/0x420
|
|
commit_cowonly_roots+0x21b/0x290
|
|
btrfs_commit_transaction+0x813/0x1360
|
|
btrfs_sync_file+0x51a/0x640
|
|
__x64_sys_fdatasync+0x52/0x90
|
|
do_syscall_64+0x9c/0x190
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
This happens because we fail to write out the free space cache in one
|
|
instance, come back around and attempt to write it again. However on
|
|
the second pass through we go to call btrfs_get_extent() on the inode to
|
|
get the extent mapping. Because this is a new block group, and with the
|
|
free space inode we always search the commit root to avoid deadlocking
|
|
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
|
|
requested range.
|
|
|
|
This happens because the first time we try to write the space cache out
|
|
we hit an error, and on an error we drop the extent mapping. This is
|
|
normal for normal files, but the free space cache inode is special. We
|
|
always expect the extent map to be correct. Thus the second time
|
|
through we end up with a bogus extent map.
|
|
|
|
Since we're deprecating this feature, the most straightforward way to
|
|
fix this is to simply skip dropping the extent map range for this failed
|
|
range.
|
|
|
|
I shortened the test by using error injection to stress the area to make
|
|
it easier to reproduce. With this patch in place we no longer panic
|
|
with my error injection test.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26726</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arp: Prevent overflow in arp_req_get().
|
|
|
|
syzkaller reported an overflown write in arp_req_get(). [0]
|
|
|
|
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
|
|
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
|
|
|
|
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
|
|
the sa_data buffer is just 14 bytes.
|
|
|
|
In the splat below, 2 bytes are overflown to the next int field,
|
|
arp_flags. We initialise the field just after the memcpy(), so it's
|
|
not a problem.
|
|
|
|
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
|
|
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
|
|
in arp_ioctl() before calling arp_req_get().
|
|
|
|
To avoid the overflow, let's limit the max length of memcpy().
|
|
|
|
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
|
|
array in struct sockaddr") just silenced syzkaller.
|
|
|
|
[0]:
|
|
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
|
|
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Modules linked in:
|
|
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
|
|
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
|
|
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
|
|
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
|
|
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
|
|
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
|
|
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
|
|
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
|
|
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
|
|
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
|
|
sock_ioctl+0x3ef/0x650 net/socket.c:1321
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:870 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:856 [inline]
|
|
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
|
|
entry_SYSCALL_64_after_hwframe+0x64/0xce
|
|
RIP: 0033:0x7f172b262b8d
|
|
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
|
|
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
|
|
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26733</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix possible use-after-free and null-ptr-deref
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26735</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: don't override retval if we already lost the skb
|
|
|
|
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
|
|
yet, we need to tell the core to drop the skb by setting the retcode
|
|
to SHOT. If we have called tcf_mirred_forward(), however, the skb
|
|
is out of our hands and returning SHOT will lead to UaF.
|
|
|
|
Move the retval override to the error path which actually need it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26739</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_mirred: use the backlog for mirred ingress
|
|
|
|
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
|
|
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
|
|
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
|
|
lockdep.
|
|
|
|
The problem as previously described by Davide (see Link) is that
|
|
if we reverse flow of traffic with the redirect (egress -> ingress)
|
|
we may reach the same socket which generated the packet. And we may
|
|
still be holding its socket lock. The common solution to such deadlocks
|
|
is to put the packet in the Rx backlog, rather than run the Rx path
|
|
inline. Do that for all egress -> ingress reversals, not just once
|
|
we started to nest mirred calls.
|
|
|
|
In the past there was a concern that the backlog indirection will
|
|
lead to loss of error reporting / less accurate stats. But the current
|
|
workaround does not seem to address the issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26740</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/qedr: Fix qedr_create_user_qp error flow
|
|
|
|
Avoid the following warning by making sure to free the allocated
|
|
resources in case that qedr_init_user_queue() fail.
|
|
|
|
-----------[ cut here ]-----------
|
|
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
|
|
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
|
|
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
|
|
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
|
|
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
|
|
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
|
|
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
|
|
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
|
|
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
|
|
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
|
|
Call Trace:
|
|
<TASK>
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? show_trace_log_lvl+0x1c4/0x2df
|
|
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? __warn+0x81/0x110
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
? report_bug+0x10a/0x140
|
|
? handle_bug+0x3c/0x70
|
|
? exc_invalid_op+0x14/0x70
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
|
|
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
|
|
__fput+0x94/0x250
|
|
task_work_run+0x5c/0x90
|
|
do_exit+0x270/0x4a0
|
|
do_group_exit+0x2d/0x90
|
|
get_signal+0x87c/0x8c0
|
|
arch_do_signal_or_restart+0x25/0x100
|
|
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
|
|
exit_to_user_mode_loop+0x9c/0x130
|
|
exit_to_user_mode_prepare+0xb6/0x100
|
|
syscall_exit_to_user_mode+0x12/0x40
|
|
do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_work+0x103/0x130
|
|
? syscall_exit_to_user_mode+0x22/0x40
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? common_interrupt+0x43/0xa0
|
|
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
|
RIP: 0033:0x1470abe3ec6b
|
|
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
|
|
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
|
|
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
|
|
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
|
|
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
|
|
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
|
|
</TASK>
|
|
--[ end trace 888a9b92e04c5c97 ]--</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26743</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Support specifying the srpt_service_guid parameter
|
|
|
|
Make loading ib_srpt with this parameter set work. The current behavior is
|
|
that setting that parameter while loading the ib_srpt kernel module
|
|
triggers the following kernel crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
Call Trace:
|
|
<TASK>
|
|
parse_one+0x18c/0x1d0
|
|
parse_args+0xe1/0x230
|
|
load_module+0x8de/0xa60
|
|
init_module_from_file+0x8b/0xd0
|
|
idempotent_init_module+0x181/0x240
|
|
__x64_sys_finit_module+0x5a/0xb0
|
|
do_syscall_64+0x5f/0xe0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26744</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</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="35" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
l2tp: pass correct message length to ip6_append_data
|
|
|
|
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
|
|
twice when splicing more data into an already partially-occupied skbuff.
|
|
|
|
To manage this, we check whether the skbuff contains data using
|
|
skb_queue_empty when deciding how much data to append using
|
|
ip6_append_data.
|
|
|
|
However, the code which performed the calculation was incorrect:
|
|
|
|
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
|
|
|
|
...due to C operator precedence, this ends up setting ulen to
|
|
transhdrlen for messages with a non-zero length, which results in
|
|
corrupted packets on the wire.
|
|
|
|
Add parentheses to correct the calculation in line with the original
|
|
intent.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26752</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.5</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
|
|
|
|
The gtp_net_ops pernet operations structure for the subsystem must be
|
|
registered before registering the generic netlink family.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
general protection fault, probably for non-canonical address
|
|
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
|
|
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
|
|
df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
|
|
3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
|
|
RSP: 0018:ffff888014107220 EFLAGS: 00010202
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
|
|
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
|
|
FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x90/0xa0
|
|
? die_addr+0x50/0xd0
|
|
? exc_general_protection+0x148/0x220
|
|
? asm_exc_general_protection+0x22/0x30
|
|
? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
|
|
? __alloc_skb+0x1dd/0x350
|
|
? __pfx___alloc_skb+0x10/0x10
|
|
genl_dumpit+0x11d/0x230
|
|
netlink_dump+0x5b9/0xce0
|
|
? lockdep_hardirqs_on_prepare+0x253/0x430
|
|
? __pfx_netlink_dump+0x10/0x10
|
|
? kasan_save_track+0x10/0x40
|
|
? __kasan_kmalloc+0x9b/0xa0
|
|
? genl_start+0x675/0x970
|
|
__netlink_dump_start+0x6fc/0x9f0
|
|
genl_family_rcv_msg_dumpit+0x1bb/0x2d0
|
|
? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
|
|
? genl_op_from_small+0x2a/0x440
|
|
? cap_capable+0x1d0/0x240
|
|
? __pfx_genl_start+0x10/0x10
|
|
? __pfx_genl_dumpit+0x10/0x10
|
|
? __pfx_genl_done+0x10/0x10
|
|
? security_capable+0x9d/0xe0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26754</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="37" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm-crypt: don't modify the data when using authenticated encryption
|
|
|
|
It was said that authenticated encryption could produce invalid tag when
|
|
the data that is being encrypted is modified [1]. So, fix this problem by
|
|
copying the data into the clone bio first and then encrypt them inside the
|
|
clone bio.
|
|
|
|
This may reduce performance, but it is needed to prevent the user from
|
|
corrupting the device by writing data with O_DIRECT and modifying them at
|
|
the same time.
|
|
|
|
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26763</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="38" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
|
|
|
|
The gtp_link_ops operations structure for the subsystem must be
|
|
registered after registering the gtp_net_ops pernet operations structure.
|
|
|
|
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
|
|
|
|
[ 1010.702740] gtp: GTP module unloaded
|
|
[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
|
|
[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
|
|
[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1
|
|
[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
|
|
[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]
|
|
[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00
|
|
[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203
|
|
[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000
|
|
[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282
|
|
[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000
|
|
[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80
|
|
[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400
|
|
[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000
|
|
[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0
|
|
[ 1010.715968] PKRU: 55555554
|
|
[ 1010.715972] Call Trace:
|
|
[ 1010.715985] ? __die_body.cold+0x1a/0x1f
|
|
[ 1010.715995] ? die_addr+0x43/0x70
|
|
[ 1010.716002] ? exc_general_protection+0x199/0x2f0
|
|
[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30
|
|
[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]
|
|
[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]
|
|
[ 1010.716042] __rtnl_newlink+0x1063/0x1700
|
|
[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0
|
|
[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0
|
|
[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0
|
|
[ 1010.716076] ? __kernel_text_address+0x56/0xa0
|
|
[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0
|
|
[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30
|
|
[ 1010.716098] ? arch_stack_walk+0x9e/0xf0
|
|
[ 1010.716106] ? stack_trace_save+0x91/0xd0
|
|
[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170
|
|
[ 1010.716121] ? __lock_acquire+0x15c5/0x5380
|
|
[ 1010.716139] ? mark_held_locks+0x9e/0xe0
|
|
[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0
|
|
[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700
|
|
[ 1010.716160] rtnl_newlink+0x69/0xa0
|
|
[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50
|
|
[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0
|
|
[ 1010.716179] ? lock_acquire+0x1fe/0x560
|
|
[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50
|
|
[ 1010.716196] netlink_rcv_skb+0x14d/0x440
|
|
[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0
|
|
[ 1010.716208] ? netlink_ack+0xab0/0xab0
|
|
[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50
|
|
[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50
|
|
[ 1010.716226] ? __virt_addr_valid+0x30b/0x590
|
|
[ 1010.716233] netlink_unicast+0x54b/0x800
|
|
[ 1010.716240] ? netlink_attachskb+0x870/0x870
|
|
[ 1010.716248] ? __check_object_size+0x2de/0x3b0
|
|
[ 1010.716254] netlink_sendmsg+0x938/0xe40
|
|
[ 1010.716261] ? netlink_unicast+0x800/0x800
|
|
[ 1010.716269] ? __import_iovec+0x292/0x510
|
|
[ 1010.716276] ? netlink_unicast+0x800/0x800
|
|
[ 1010.716284] __sock_sendmsg+0x159/0x190
|
|
[ 1010.716290] ____sys_sendmsg+0x712/0x880
|
|
[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0
|
|
[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270
|
|
[ 1010.716309] ? lock_acquire+0x1fe/0x560
|
|
[ 1010.716315] ? drain_array_locked+0x90/0x90
|
|
[ 1010.716324] ___sys_sendmsg+0xf8/0x170
|
|
[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170
|
|
[ 1010.716337] ? lockdep_init_map
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26793</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="40" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Avoid potential use-after-free in hci_error_reset
|
|
|
|
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
|
|
BT controller is not responding, the GPIO reset mechanism would
|
|
free the hci_dev and lead to a use-after-free in hci_error_reset.
|
|
|
|
Here's the call trace observed on a ChromeOS device with Intel AX201:
|
|
queue_work_on+0x3e/0x6c
|
|
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
|
|
? init_wait_entry+0x31/0x31
|
|
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
|
|
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
|
|
process_one_work+0x1d8/0x33f
|
|
worker_thread+0x21b/0x373
|
|
kthread+0x13a/0x152
|
|
? pr_cont_work+0x54/0x54
|
|
? kthread_blkcg+0x31/0x31
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This patch holds the reference count on the hci_dev while processing
|
|
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26801</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ip_tunnel: prevent perpetual headroom growth
|
|
|
|
syzkaller triggered following kasan splat:
|
|
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
|
|
[..]
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:588
|
|
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
|
|
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
|
|
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
|
|
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
|
|
skb_get_hash include/linux/skbuff.h:1556 [inline]
|
|
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
|
|
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
|
|
...
|
|
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
|
|
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
|
|
..
|
|
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
|
|
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
|
|
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
|
|
...
|
|
|
|
The splat occurs because skb->data points past skb->head allocated area.
|
|
This is because neigh layer does:
|
|
__skb_pull(skb, skb_network_offset(skb));
|
|
|
|
... but skb_network_offset() returns a negative offset and __skb_pull()
|
|
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
|
|
|
|
The negative value is returned because skb->head and skb->data distance is
|
|
more than 64k and skb->network_header (u16) has wrapped around.
|
|
|
|
The bug is in the ip_tunnel infrastructure, which can cause
|
|
dev->needed_headroom to increment ad infinitum.
|
|
|
|
The syzkaller reproducer consists of packets getting routed via a gre
|
|
tunnel, and route of gre encapsulated packets pointing at another (ipip)
|
|
tunnel. The ipip encapsulation finds gre0 as next output device.
|
|
|
|
This results in the following pattern:
|
|
|
|
1). First packet is to be sent out via gre0.
|
|
Route lookup found an output device, ipip0.
|
|
|
|
2).
|
|
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
|
|
output device, rt.dev->needed_headroom (ipip0).
|
|
|
|
3).
|
|
ip output / start_xmit moves skb on to ipip0. which runs the same
|
|
code path again (xmit recursion).
|
|
|
|
4).
|
|
Routing step for the post-gre0-encap packet finds gre0 as output device
|
|
to use for ipip0 encapsulated packet.
|
|
|
|
tunl0->needed_headroom is then incremented based on the (already bumped)
|
|
gre0 device headroom.
|
|
|
|
This repeats for every future packet:
|
|
|
|
gre0->needed_headroom gets inflated because previous packets' ipip0 step
|
|
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
|
|
needed_headroom was increased.
|
|
|
|
For each subsequent packet, gre/ipip0->needed_headroom grows until
|
|
post-expand-head reallocations result in a skb->head/data distance of
|
|
more than 64k.
|
|
|
|
Once that happens, skb->network_header (u16) wraps around when
|
|
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
|
|
after the headroom expansion/reallocation.
|
|
|
|
After this skb_network_offset(skb) returns a different (and negative)
|
|
result post headroom expansion.
|
|
|
|
The next trip to neigh layer (or anything else that would __skb_pull the
|
|
network header) makes skb->data point to a memory location outside
|
|
skb->head area.
|
|
|
|
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
|
|
prevent perpetual increase instead of dropping the headroom increment
|
|
completely.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26804</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
|
|
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
|
|
size is specified as `len` and passed to skb_put_data(). This `len`
|
|
is based on `skb->end` that is not data offset but buffer offset. The
|
|
`skb->end` contains data and tailroom. Since the tailroom is not
|
|
initialized when the new `skb` created, KMSAN detects uninitialized
|
|
memory area when copying the data.
|
|
|
|
This patch resolved this issue by correct the len from `skb->end` to
|
|
`skb->len`, which is the actual data offset.
|
|
|
|
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
|
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
|
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
|
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
|
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
|
|
copy_to_iter include/linux/uio.h:197 [inline]
|
|
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
|
|
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
|
|
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
|
|
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
|
|
sock_recvmsg_nosec net/socket.c:1044 [inline]
|
|
sock_recvmsg net/socket.c:1066 [inline]
|
|
sock_read_iter+0x467/0x580 net/socket.c:1136
|
|
call_read_iter include/linux/fs.h:2014 [inline]
|
|
new_sync_read fs/read_write.c:389 [inline]
|
|
vfs_read+0x8f6/0xe00 fs/read_write.c:470
|
|
ksys_read+0x20f/0x4c0 fs/read_write.c:613
|
|
__do_sys_read fs/read_write.c:623 [inline]
|
|
__se_sys_read fs/read_write.c:621 [inline]
|
|
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was stored to memory at:
|
|
skb_put_data include/linux/skbuff.h:2622 [inline]
|
|
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
|
|
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
|
|
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
|
|
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
|
|
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
free_pages_prepare mm/page_alloc.c:1087 [inline]
|
|
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
|
|
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
|
|
release_pages+0x23d3/0x2410 mm/swap.c:1042
|
|
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
|
|
tlb_batch_pages
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26805</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26812</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/platform: Create persistent IRQ handlers
|
|
|
|
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
|
|
an interrupt before a signaling eventfd has been configured by the user,
|
|
which thereby allows a NULL pointer dereference.
|
|
|
|
Rather than register the IRQ relative to a valid trigger, register all
|
|
IRQs in a disabled state in the device open path. This allows mask
|
|
operations on the IRQ to nest within the overall enable state governed
|
|
by a valid eventfd signal. This decouples @masked, protected by the
|
|
@locked spinlock from @trigger, protected via the @igate mutex.
|
|
|
|
In doing so, it's guaranteed that changes to @trigger cannot race the
|
|
IRQ handlers because the IRQ handler is synchronously disabled before
|
|
modifying the trigger, and loopback triggering of the IRQ via ioctl is
|
|
safe due to serialization with trigger changes via igate.
|
|
|
|
For compatibility, request_irq() failures are maintained to be local to
|
|
the SET_IRQS ioctl rather than a fatal error in the open device path.
|
|
This allows, for example, a userspace driver with polling mode support
|
|
to continue to work regardless of moving the request_irq() call site.
|
|
This necessarily blocks all SET_IRQS access to the failed index.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26813</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26817</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26828</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.3</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26839</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26840</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvme-fc: do not wait in vain when unloading module
|
|
|
|
The module exit path has race between deleting all controllers and
|
|
freeing 'left over IDs'. To prevent double free a synchronization
|
|
between nvme_delete_ctrl and ida_destroy has been added by the initial
|
|
commit.
|
|
|
|
There is some logic around trying to prevent from hanging forever in
|
|
wait_for_completion, though it does not handling all cases. E.g.
|
|
blktests is able to reproduce the situation where the module unload
|
|
hangs forever.
|
|
|
|
If we completely rely on the cleanup code executed from the
|
|
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
|
|
calling ida_destroy unnecessary. We only have to ensure that all
|
|
nvme_delete_ctrl code has been executed before we leave
|
|
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
|
|
workqueue.
|
|
|
|
While at it, remove the unused nvme_fc_wq workqueue too.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26846</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
|
|
|
|
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
|
|
|
|
Commit f7225172f25a ("net/ipv6: prevent use after free in
|
|
ip6_route_mpath_notify") was not able to fix the root cause.
|
|
|
|
We need to defer the fib6_info_release() calls after
|
|
ip6_route_mpath_notify(), in the cleanup phase.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
|
|
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
|
|
|
|
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x167/0x540 mm/kasan/report.c:488
|
|
kasan_report+0x142/0x180 mm/kasan/report.c:601
|
|
rt6_fill_node+0x1460/0x1ac0
|
|
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
|
|
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
|
|
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
|
|
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7f73dd87dda9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
|
|
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
|
|
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
|
|
</TASK>
|
|
|
|
Allocated by task 23037:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3981 [inline]
|
|
__kmalloc+0x22e/0x490 mm/slub.c:3994
|
|
kmalloc include/linux/slab.h:594 [inline]
|
|
kzalloc include/linux/slab.h:711 [inline]
|
|
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
|
|
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
|
|
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
|
|
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
|
|
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
|
|
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
|
|
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
|
|
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x221/0x270 net/socket.c:745
|
|
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
|
|
___sys_sendmsg net/socket.c:2638 [inline]
|
|
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
|
|
do_syscall_64+0xf9/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
|
|
Freed by task 16:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object+0xa6/0xe0 m
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26852</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
geneve: make sure to pull inner header in geneve_rx()
|
|
|
|
syzbot triggered a bug in geneve_rx() [1]
|
|
|
|
Issue is similar to the one I fixed in commit 8d975c15c0cd
|
|
("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
|
|
|
|
We have to save skb->network_header in a temporary variable
|
|
in order to be able to recompute the network_header pointer
|
|
after a pskb_inet_may_pull() call.
|
|
|
|
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
|
|
IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
|
|
geneve_rx drivers/net/geneve.c:279 [inline]
|
|
geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
|
|
udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
|
|
udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
|
|
udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
|
|
__udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
|
|
udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
|
|
ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
|
|
ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
|
|
__netif_receive_skb_one_core net/core/dev.c:5534 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
|
|
process_backlog+0x480/0x8b0 net/core/dev.c:5976
|
|
__napi_poll+0xe3/0x980 net/core/dev.c:6576
|
|
napi_poll net/core/dev.c:6645 [inline]
|
|
net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
|
|
__do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
|
|
do_softirq+0x9a/0xf0 kernel/softirq.c:454
|
|
__local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
|
|
local_bh_enable include/linux/bottom_half.h:33 [inline]
|
|
rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
|
|
__dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
|
|
dev_queue_xmit include/linux/netdevice.h:3171 [inline]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3081 [inline]
|
|
packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slub.c:3819 [inline]
|
|
slab_alloc_node mm/slub.c:3860 [inline]
|
|
kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x352/0x790 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1296 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
|
|
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
|
|
packet_snd net/packet/af_packet.c:3024 [inline]
|
|
packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26857</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/bnx2x: Prevent access to a freed page in page_pool
|
|
|
|
Fix race condition leading to system crash during EEH error handling
|
|
|
|
During EEH error recovery, the bnx2x driver's transmit timeout logic
|
|
could cause a race condition when handling reset tasks. The
|
|
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
|
|
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
|
|
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
|
|
overlap with the EEH driver's attempt to reset the device using
|
|
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
|
|
condition can result in system crashes due to accessing freed memory
|
|
locations in bnx2x_free_rx_sge()
|
|
|
|
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
|
|
800 struct bnx2x_fastpath *fp, u16 index)
|
|
801 {
|
|
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
|
|
803 struct page *page = sw_buf->page;
|
|
....
|
|
where sw_buf was set to NULL after the call to dma_unmap_page()
|
|
by the preceding thread.
|
|
|
|
EEH: Beginning: 'slot_reset'
|
|
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
|
|
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
|
|
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
|
|
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
|
|
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
|
|
BUG: Kernel NULL pointer dereference on read at 0x00000000
|
|
Faulting instruction address: 0xc0080000025065fc
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
.....
|
|
Call Trace:
|
|
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
|
|
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
|
|
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
|
|
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
|
|
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
|
|
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
|
|
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
|
|
|
|
To solve this issue, we need to verify page pool allocations before
|
|
freeing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26859</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hsr: Fix uninit-value access in hsr_get_node()
|
|
|
|
KMSAN reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
|
|
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
|
|
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
|
|
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3087 [inline]
|
|
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
|
|
packet_snd net/packet/af_packet.c:3030 [inline]
|
|
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
__sys_sendto+0x735/0xa10 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
=====================================================
|
|
|
|
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
|
|
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
|
|
reads an invalid value as a sequence number. This causes the above issue.
|
|
|
|
This patch fixes the issue by returning NULL if the Ethernet header is not
|
|
followed by an HSR tag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26863</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srpt: Do not register event handler until srpt device is fully setup
|
|
|
|
Upon rare occasions, KASAN reports a use-after-free Write
|
|
in srpt_refresh_port().
|
|
|
|
This seems to be because an event handler is registered before the
|
|
srpt device is fully setup and a race condition upon error may leave a
|
|
partially setup event handler in place.
|
|
|
|
Instead, only register the event handler after srpt device initialization
|
|
is complete.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26872</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26875</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="56" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="56" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: adv7511: fix crash on irq during probe
|
|
|
|
Moved IRQ registration down to end of adv7511_probe().
|
|
|
|
If an IRQ already is pending during adv7511_probe
|
|
(before adv7511_cec_init) then cec_received_msg_ts
|
|
could crash using uninitialized data:
|
|
|
|
Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
|
|
Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
|
|
Call trace:
|
|
cec_received_msg_ts+0x48/0x990 [cec]
|
|
adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
|
|
adv7511_irq_process+0xd8/0x120 [adv7511]
|
|
adv7511_irq_handler+0x1c/0x30 [adv7511]
|
|
irq_thread_fn+0x30/0xa0
|
|
irq_thread+0x14c/0x238
|
|
kthread+0x190/0x1a8</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26876</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="57" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="57" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26878</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="58" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="58" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm: call the resume method on internal suspend
|
|
|
|
There is this reported crash when experimenting with the lvm2 testsuite.
|
|
The list corruption is caused by the fact that the postsuspend and resume
|
|
methods were not paired correctly; there were two consecutive calls to the
|
|
origin_postsuspend function. The second call attempts to remove the
|
|
"hash_list" entry from a list, while it was already removed by the first
|
|
call.
|
|
|
|
Fix __dm_internal_resume so that it calls the preresume and resume
|
|
methods of the table's targets.
|
|
|
|
If a preresume method of some target fails, we are in a tricky situation.
|
|
We can't return an error because dm_internal_resume isn't supposed to
|
|
return errors. We can't return success, because then the "resume" and
|
|
"postsuspend" methods would not be paired correctly. So, we set the
|
|
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
|
|
tools, but it won't cause a kernel crash.
|
|
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/list_debug.c:56!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
|
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
|
|
<snip>
|
|
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
|
|
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
|
|
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
|
|
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
|
|
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
|
|
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
|
|
FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
|
|
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
|
|
Call Trace:
|
|
<TASK>
|
|
? die+0x2d/0x80
|
|
? do_trap+0xeb/0xf0
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? do_error_trap+0x60/0x80
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? exc_invalid_op+0x49/0x60
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
? __list_del_entry_valid_or_report+0x77/0xc0
|
|
origin_postsuspend+0x1a/0x50 [dm_snapshot]
|
|
dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
|
|
dm_suspend+0xd8/0xf0 [dm_mod]
|
|
dev_suspend+0x1f2/0x2f0 [dm_mod]
|
|
? table_deps+0x1b0/0x1b0 [dm_mod]
|
|
ctl_ioctl+0x300/0x5f0 [dm_mod]
|
|
dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
|
|
__x64_compat_sys_ioctl+0x104/0x170
|
|
do_syscall_64+0x184/0x1b0
|
|
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
|
RIP: 0033:0xf7e6aead
|
|
<snip>
|
|
---[ end trace 0000000000000000 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26880</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="59" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="59" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
|
|
|
|
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
|
|
structures have been fully initialised by the time it runs. However, because of
|
|
the order in which things are initialised, this is not guaranteed to be the
|
|
case, because the device is exposed to the USB subsystem before the ath9k driver
|
|
initialisation is completed.
|
|
|
|
We already committed a partial fix for this in commit:
|
|
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
|
|
|
|
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
|
|
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
|
|
seems syzbot managed to trigger the race for one of the other commands as well,
|
|
so let's just move the existing synchronisation bit to cover the whole
|
|
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
|
|
ath9k_tx_init()).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26897</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="60" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="60" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:aoe: fix the potential use-after-free problem in aoecmd_cfg_pktsThis patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initialcode is finished. But the net_device ifp will still be used inlater tx()->dev_queue_xmit() in kthread. Which means that thedev_put(ifp) should NOT be called in the success path of skbinitial code in aoecmd_cfg_pkts(). Otherwise tx() may run intouse-after-free because the net_device is freed.This patch removed the dev_put(ifp) in the success path inaoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="61" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="61" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Reset IH OVERFLOW_CLEAR bit
|
|
|
|
Allows us to detect subsequent IH ring buffer overflows as well.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26915</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="62" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="62" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: validate the parameters of bo mapping operations more clearly
|
|
|
|
Verify the parameters of
|
|
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26922</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="63" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="63" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: go7007: fix a memleak in go7007_load_encoder
|
|
|
|
In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
|
|
a deallocation thereafter. After the following call chain:
|
|
|
|
saa7134_go7007_init
|
|
|-> go7007_boot_encoder
|
|
|-> go7007_load_encoder
|
|
|-> kfree(go)
|
|
|
|
go is freed and thus bounce is leaked.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-27074</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1618</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |