6904 lines
307 KiB
XML
6904 lines
307 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS</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-1647</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-24</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-24</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-24</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-24</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS.</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:
|
|
|
|
i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()
|
|
|
|
memcpy() is called in a loop while 'operation->length' upper bound
|
|
is not checked and 'data_idx' also increments.(CVE-2022-48632)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/slub: fix to return errno if kmalloc() fails
|
|
|
|
In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
|
|
out-of-memory, if it fails, return errno correctly rather than
|
|
triggering panic via BUG_ON();
|
|
|
|
kernel BUG at mm/slub.c:5893!
|
|
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
|
|
|
|
Call trace:
|
|
sysfs_slab_add+0x258/0x260 mm/slub.c:5973
|
|
__kmem_cache_create+0x60/0x118 mm/slub.c:4899
|
|
create_cache mm/slab_common.c:229 [inline]
|
|
kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
|
|
kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
|
|
f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
|
|
f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
|
|
f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
|
|
mount_bdev+0x1b8/0x210 fs/super.c:1400
|
|
f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
|
|
legacy_get_tree+0x30/0x74 fs/fs_context.c:610
|
|
vfs_get_tree+0x40/0x140 fs/super.c:1530
|
|
do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
|
|
path_mount+0x358/0x914 fs/namespace.c:3370
|
|
do_mount fs/namespace.c:3383 [inline]
|
|
__do_sys_mount fs/namespace.c:3591 [inline]
|
|
__se_sys_mount fs/namespace.c:3568 [inline]
|
|
__arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568(CVE-2022-48659)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
|
|
|
|
When running gpio test on nxp-ls1028 platform with below command
|
|
gpiomon --num-events=3 --rising-edge gpiochip1 25
|
|
There will be a warning trace as below:
|
|
Call trace:
|
|
free_irq+0x204/0x360
|
|
lineevent_free+0x64/0x70
|
|
gpio_ioctl+0x598/0x6a0
|
|
__arm64_sys_ioctl+0xb4/0x100
|
|
invoke_syscall+0x5c/0x130
|
|
......
|
|
el0t_64_sync+0x1a0/0x1a4
|
|
The reason of this issue is that calling request_threaded_irq()
|
|
function failed, and then lineevent_free() is invoked to release
|
|
the resource. Since the lineevent_state::irq was already set, so
|
|
the subsequent invocation of free_irq() would trigger the above
|
|
warning call trace. To fix this issue, set the lineevent_state::irq
|
|
after the IRQ register successfully.(CVE-2022-48660)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: fix race between mmput() and do_exit()
|
|
|
|
Task A calls binder_update_page_range() to allocate and insert pages on
|
|
a remote address space from Task B. For this, Task A pins the remote mm
|
|
via mmget_not_zero() first. This can race with Task B do_exit() and the
|
|
final mmput() refcount decrement will come from Task A.
|
|
|
|
Task A | Task B
|
|
------------------+------------------
|
|
mmget_not_zero() |
|
|
| do_exit()
|
|
| exit_mm()
|
|
| mmput()
|
|
mmput() |
|
|
exit_mmap() |
|
|
remove_vma() |
|
|
fput() |
|
|
|
|
In this case, the work of ____fput() from Task B is queued up in Task A
|
|
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
|
|
work gets executed. However, Task A instead sleep, waiting for a reply
|
|
from Task B that never comes (it's dead).
|
|
|
|
This means the binder_deferred_release() is blocked until an unrelated
|
|
binder event forces Task A to go back to userspace. All the associated
|
|
death notifications will also be delayed until then.
|
|
|
|
In order to fix this use mmput_async() that will schedule the work in
|
|
the corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)
|
|
|
|
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:
|
|
|
|
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
|
|
|
|
When the mpi_ec_ctx structure is initialized, some fields are not
|
|
cleared, causing a crash when referencing the field when the
|
|
structure was released. Initially, this issue was ignored because
|
|
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
|
|
For example, this error will be triggered when calculating the
|
|
Za value for SM2 separately.(CVE-2023-52616)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block/rnbd-srv: Check for unlikely string overflow
|
|
|
|
Since "dev_search_path" can technically be as large as PATH_MAX,
|
|
there was a risk of truncation when copying it and a second string
|
|
into "full_path" since it was also PATH_MAX sized. The W=1 builds were
|
|
reporting this warning:
|
|
|
|
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
|
|
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~
|
|
In function 'rnbd_srv_get_full_path',
|
|
inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
617 | dev_search_path, dev_name);
|
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fix this, unconditionally check for truncation (as was already done
|
|
for the case where "%SESSNAME%" was present).(CVE-2023-52618)
|
|
|
|
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:
|
|
|
|
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
|
|
|
|
These three bpf_map_{lookup,update,delete}_elem() helpers are also
|
|
available for sleepable bpf program, so add the corresponding lock
|
|
assertion for sleepable bpf program, otherwise the following warning
|
|
will be reported when a sleepable bpf program manipulates bpf map under
|
|
interpreter mode (aka bpf_jit_enable=0):
|
|
|
|
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
|
|
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
|
|
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
|
|
......
|
|
Call Trace:
|
|
<TASK>
|
|
? __warn+0xa5/0x240
|
|
? bpf_map_lookup_elem+0x54/0x60
|
|
? report_bug+0x1ba/0x1f0
|
|
? handle_bug+0x40/0x80
|
|
? exc_invalid_op+0x18/0x50
|
|
? asm_exc_invalid_op+0x1b/0x20
|
|
? __pfx_bpf_map_lookup_elem+0x10/0x10
|
|
? rcu_lockdep_current_cpu_online+0x65/0xb0
|
|
? rcu_is_watching+0x23/0x50
|
|
? bpf_map_lookup_elem+0x54/0x60
|
|
? __pfx_bpf_map_lookup_elem+0x10/0x10
|
|
___bpf_prog_run+0x513/0x3b70
|
|
__bpf_prog_run32+0x9d/0xd0
|
|
? __bpf_prog_enter_sleepable_recur+0xad/0x120
|
|
? __bpf_prog_enter_sleepable_recur+0x3e/0x120
|
|
bpf_trampoline_6442580665+0x4d/0x1000
|
|
__x64_sys_getpgid+0x5/0x30
|
|
? do_syscall_64+0x36/0xb0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
</TASK>(CVE-2023-52621)
|
|
|
|
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)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52630)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
um: time-travel: fix time corruption
|
|
|
|
In 'basic' time-travel mode (without =inf-cpu or =ext), we
|
|
still get timer interrupts. These can happen at arbitrary
|
|
points in time, i.e. while in timer_read(), which pushes
|
|
time forward just a little bit. Then, if we happen to get
|
|
the interrupt after calculating the new time to push to,
|
|
but before actually finishing that, the interrupt will set
|
|
the time to a value that's incompatible with the forward,
|
|
and we'll crash because time goes backwards when we do the
|
|
forwarding.
|
|
|
|
Fix this by reading the time_travel_time, calculating the
|
|
adjustment, and doing the adjustment all with interrupts
|
|
disabled.(CVE-2023-52633)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: aqc111: check packet for fixup for true limit
|
|
|
|
If a device sends a packet that is inbetween 0
|
|
and sizeof(u64) the value passed to skb_trim()
|
|
as length will wrap around ending up as some very
|
|
large value.
|
|
|
|
The driver will then proceed to parse the header
|
|
located at that position, which will either oops or
|
|
process some random value.
|
|
|
|
The fix is to check against sizeof(u64) rather than
|
|
0, which the driver currently does. The issue exists
|
|
since the introduction of the driver.(CVE-2023-52655)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.(CVE-2023-52675)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Guard stack limits against 32bit overflow
|
|
|
|
This patch promotes the arithmetic around checking stack bounds to be
|
|
done in the 64-bit domain, instead of the current 32bit. The arithmetic
|
|
implies adding together a 64-bit register with a int offset. The
|
|
register was checked to be below 1<<29 when it was variable, but not
|
|
when it was fixed. The offset either comes from an instruction (in which
|
|
case it is 16 bit), from another register (in which case the caller
|
|
checked it to be below 1<<29 [1]), or from the size of an argument to a
|
|
kfunc (in which case it can be a u32 [2]). Between the register being
|
|
inconsistently checked to be below 1<<29, and the offset being up to an
|
|
u32, it appears that we were open to overflowing the `int`s which were
|
|
currently used for arithmetic.
|
|
|
|
[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498
|
|
[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904(CVE-2023-52676)
|
|
|
|
|
|
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
(CVE-2024-24860)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: fix a memory corruption
|
|
|
|
iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
|
|
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
|
|
bytes, we'll write past the buffer.(CVE-2024-26610)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__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]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
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:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__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]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
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_sendms
|
|
---truncated---(CVE-2024-26633)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
llc: Drop support for ETH_P_TR_802_2.
|
|
|
|
syzbot reported an uninit-value bug below. [0]
|
|
|
|
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
|
|
(0x0011), and syzbot abused the latter to trigger the bug.
|
|
|
|
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
|
|
|
|
llc_conn_handler() initialises local variables {saddr,daddr}.mac
|
|
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
|
|
them to __llc_lookup().
|
|
|
|
However, the initialisation is done only when skb->protocol is
|
|
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
|
|
__llc_lookup_listener() will read garbage.
|
|
|
|
The missing initialisation existed prior to commit 211ed865108e
|
|
("net: delete all instances of special processing for token ring").
|
|
|
|
It removed the part to kick out the token ring stuff but forgot to
|
|
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
|
|
|
|
Let's remove llc_tr_packet_type and complete the deprecation.
|
|
|
|
[0]:
|
|
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup net/llc/llc_conn.c:611 [inline]
|
|
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
|
|
netif_receive_skb_internal net/core/dev.c:5727 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x1490 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Local variable daddr created at:
|
|
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
|
|
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
llc: make llc_ui_sendmsg() more robust against bonding changes
|
|
|
|
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
|
|
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
|
|
|
|
Like some others, llc_ui_sendmsg() releases the socket lock before
|
|
calling sock_alloc_send_skb().
|
|
Then it acquires it again, but does not redo all the sanity checks
|
|
that were performed.
|
|
|
|
This fix:
|
|
|
|
- Uses LL_RESERVED_SPACE() to reserve space.
|
|
- Check all conditions again after socket lock is held again.
|
|
- Do not account Ethernet header for mtu limitation.
|
|
|
|
[1]
|
|
|
|
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
|
|
|
|
kernel BUG at net/core/skbuff.c:193 !
|
|
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in:
|
|
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : skb_panic net/core/skbuff.c:189 [inline]
|
|
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
lr : skb_panic net/core/skbuff.c:189 [inline]
|
|
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
sp : ffff800096f97000
|
|
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
|
|
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
|
|
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
|
|
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
|
|
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
|
|
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
|
|
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
|
|
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
|
|
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
|
|
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
|
|
Call trace:
|
|
skb_panic net/core/skbuff.c:189 [inline]
|
|
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
skb_push+0xf0/0x108 net/core/skbuff.c:2451
|
|
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
|
|
dev_hard_header include/linux/netdevice.h:3188 [inline]
|
|
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
|
|
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
|
|
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
|
|
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
|
|
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
|
|
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
|
|
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_sendmsg+0x194/0x274 net/socket.c:767
|
|
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
|
|
do_splice_from fs/splice.c:933 [inline]
|
|
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
|
|
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
|
|
do_splice_direct+0x20c/0x348 fs/splice.c:1194
|
|
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
|
|
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
|
|
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
|
|
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
|
|
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
|
|
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
|
|
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
|
|
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
|
|
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
|
|
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
|
|
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
|
|
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: add sanity checks to rx zerocopy
|
|
|
|
TCP rx zerocopy intent is to map pages initially allocated
|
|
from NIC drivers, not pages owned by a fs.
|
|
|
|
This patch adds to can_map_frag() these additional checks:
|
|
|
|
- Page must not be a compound one.
|
|
- page->mapping must be NULL.
|
|
|
|
This fixes the panic reported by ZhangPeng.
|
|
|
|
syzbot was able to loopback packets built with sendfile(),
|
|
mapping pages owned by an ext4 file to TCP rx zerocopy.
|
|
|
|
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
|
|
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
|
|
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
|
|
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)
|
|
fallocate(r5, 0x0, 0x0, 0x85b8)
|
|
sendfile(r4, r5, 0x0, 0x8ba0)
|
|
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
|
|
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
|
|
0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
|
|
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)(CVE-2024-26640)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
|
|
|
|
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
|
|
|
|
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
|
|
variable after this call as it can change skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
|
|
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
|
|
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
|
|
gre_rcv+0x143f/0x1870
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
|
|
netif_receive_skb_internal net/core/dev.c:5732 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
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
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
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: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)
|
|
|
|
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:
|
|
|
|
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
|
|
|
|
In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"
|
|
pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to
|
|
ensure the tg is not NULL.(CVE-2024-26661)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tunnels: fix out of bounds access when building IPv6 PMTU error
|
|
|
|
If the ICMPv6 error is built from a non-linear skb we get the following
|
|
splat,
|
|
|
|
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
|
|
Read of size 4 at addr ffff88811d402c80 by task netperf/820
|
|
CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
|
|
...
|
|
kasan_report+0xd8/0x110
|
|
do_csum+0x220/0x240
|
|
csum_partial+0xc/0x20
|
|
skb_tunnel_check_pmtu+0xeb9/0x3280
|
|
vxlan_xmit_one+0x14c2/0x4080
|
|
vxlan_xmit+0xf61/0x5c00
|
|
dev_hard_start_xmit+0xfb/0x510
|
|
__dev_queue_xmit+0x7cd/0x32a0
|
|
br_dev_queue_push_xmit+0x39d/0x6a0
|
|
|
|
Use skb_checksum instead of csum_partial who cannot deal with non-linear
|
|
SKBs.(CVE-2024-26665)
|
|
|
|
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:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---(CVE-2024-26669)
|
|
|
|
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:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
|
|
|
|
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
|
|
XGMAC core") checks and reports safety errors, but leaves the
|
|
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
|
|
a storm of interrupt.
|
|
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)
|
|
|
|
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:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)
|
|
|
|
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:
|
|
|
|
iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
|
|
|
|
Recently, we encounter kernel crash in function rm3100_common_probe
|
|
caused by out of bound access of array rm3100_samp_rates (because of
|
|
underlying hardware failures). Add boundary check to prevent out of
|
|
bound access.(CVE-2024-26702)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
parisc: Fix random data corruption from exception handler
|
|
|
|
The current exception handler implementation, which assists when accessing
|
|
user space memory, may exhibit random data corruption if the compiler decides
|
|
to use a different register than the specified register %r29 (defined in
|
|
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
|
|
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
|
|
trash whatever this register is used for.
|
|
Looking at the assembly I found that this happens sometimes in emulate_ldd().
|
|
|
|
To solve the issue, the easiest solution would be if it somehow is
|
|
possible to tell the fault handler which register is used to hold the error
|
|
code. Using %0 or %1 in the inline assembly is not posssible as it will show
|
|
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
|
|
convert to an integer.
|
|
|
|
This patch takes another, better and more flexible approach:
|
|
We extend the __ex_table (which is out of the execution path) by one 32-word.
|
|
In this word we tell the compiler to insert the assembler instruction
|
|
"or %r0,%r0,%reg", where %reg references the register which the compiler
|
|
choosed for the error return code.
|
|
In case of an access failure, the fault handler finds the __ex_table entry and
|
|
can examine the opcode. The used register is encoded in the lowest 5 bits, and
|
|
the fault handler can then store -EFAULT into this register.
|
|
|
|
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
|
|
config option any longer.(CVE-2024-26706)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
|
|
|
|
Syzkaller reported [1] hitting a warning after failing to allocate
|
|
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
|
|
not help much in this case, it might be prudent to switch to
|
|
netdev_warn_once(). At the very least it will suppress syzkaller
|
|
reports such as [1].
|
|
|
|
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
|
|
for similar reasons.
|
|
|
|
[1]
|
|
HSR: Could not send supervision frame
|
|
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
|
|
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
|
|
expire_timers kernel/time/timer.c:1751 [inline]
|
|
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
|
|
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
invoke_softirq kernel/softirq.c:427 [inline]
|
|
__irq_exit_rcu kernel/softirq.c:632 [inline]
|
|
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
|
|
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
|
|
...
|
|
|
|
This issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/kasan: Fix addr error caused by page alignment
|
|
|
|
In kasan_init_region, when k_start is not page aligned, at the begin of
|
|
for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
|
|
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
|
|
because the memory address space from va to block is not alloced by
|
|
memblock_alloc, which will not be reserved by memblock_reserve later, it
|
|
will be used by other places.
|
|
|
|
As a result, memory overwriting occurs.
|
|
|
|
for example:
|
|
int __init __weak kasan_init_region(void *start, size_t size)
|
|
{
|
|
[...]
|
|
/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
|
|
block = memblock_alloc(k_end - k_start, PAGE_SIZE);
|
|
[...]
|
|
for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
|
|
/* at the begin of for loop
|
|
* block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
|
|
* va(dcd96c00) is less than block(dcd97000), va is invalid
|
|
*/
|
|
void *va = block + k_cur - k_start;
|
|
[...]
|
|
}
|
|
[...]
|
|
}
|
|
|
|
Therefore, page alignment is performed on k_start before
|
|
memblock_alloc() to ensure the validity of the VA address.(CVE-2024-26712)
|
|
|
|
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:
|
|
|
|
devlink: fix possible use-after-free and memory leaks in devlink_init()
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.
|
|
|
|
Make an unregister in case of unsuccessful registration.(CVE-2024-26734)
|
|
|
|
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: 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:
|
|
|
|
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:
|
|
|
|
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
|
|
|
|
Return IRQ_NONE from the interrupt handler when no interrupt was
|
|
detected. Because an empty interrupt will cause a null pointer error:
|
|
|
|
Unable to handle kernel NULL pointer dereference at virtual
|
|
address 0000000000000008
|
|
Call trace:
|
|
complete+0x54/0x100
|
|
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
|
|
__handle_irq_event_percpu+0x64/0x1e0
|
|
handle_irq_event+0x7c/0x1cc(CVE-2024-26776)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: fix double-free on socket dismantle
|
|
|
|
when MPTCP server accepts an incoming connection, it clones its listener
|
|
socket. However, the pointer to 'inet_opt' for the new socket has the same
|
|
value as the original one: as a consequence, on program exit it's possible
|
|
to observe the following splat:
|
|
|
|
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
|
|
Free of addr ffff888485950880 by task swapper/25/0
|
|
|
|
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
|
|
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl+0x32/0x50
|
|
print_report+0xca/0x620
|
|
kasan_report_invalid_free+0x64/0x90
|
|
__kasan_slab_free+0x1aa/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
rcu_do_batch+0x34e/0xd90
|
|
rcu_core+0x559/0xac0
|
|
__do_softirq+0x183/0x5a4
|
|
irq_exit_rcu+0x12d/0x170
|
|
sysvec_apic_timer_interrupt+0x6b/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x16/0x20
|
|
RIP: 0010:cpuidle_enter_state+0x175/0x300
|
|
Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b
|
|
RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
|
|
RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
|
|
RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
|
|
RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
|
|
R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
|
|
R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
|
|
cpuidle_enter+0x4a/0xa0
|
|
do_idle+0x310/0x410
|
|
cpu_startup_entry+0x51/0x60
|
|
start_secondary+0x211/0x270
|
|
secondary_startup_64_no_verify+0x184/0x18b
|
|
</TASK>
|
|
|
|
Allocated by task 6853:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
__kasan_kmalloc+0xa6/0xb0
|
|
__kmalloc+0x1eb/0x450
|
|
cipso_v4_sock_setattr+0x96/0x360
|
|
netlbl_sock_setattr+0x132/0x1f0
|
|
selinux_netlbl_socket_post_create+0x6c/0x110
|
|
selinux_socket_post_create+0x37b/0x7f0
|
|
security_socket_post_create+0x63/0xb0
|
|
__sock_create+0x305/0x450
|
|
__sys_socket_create.part.23+0xbd/0x130
|
|
__sys_socket+0x37/0xb0
|
|
__x64_sys_socket+0x6f/0xb0
|
|
do_syscall_64+0x83/0x160
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Freed by task 6858:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
__kasan_slab_free+0x12c/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
subflow_ulp_release+0x1f0/0x250
|
|
tcp_cleanup_ulp+0x6e/0x110
|
|
tcp_v4_destroy_sock+0x5a/0x3a0
|
|
inet_csk_destroy_sock+0x135/0x390
|
|
tcp_fin+0x416/0x5c0
|
|
tcp_data_queue+0x1bc8/0x4310
|
|
tcp_rcv_state_process+0x15a3/0x47b0
|
|
tcp_v4_do_rcv+0x2c1/0x990
|
|
tcp_v4_rcv+0x41fb/0x5ed0
|
|
ip_protocol_deliver_rcu+0x6d/0x9f0
|
|
ip_local_deliver_finish+0x278/0x360
|
|
ip_local_deliver+0x182/0x2c0
|
|
ip_rcv+0xb5/0x1c0
|
|
__netif_receive_skb_one_core+0x16e/0x1b0
|
|
process_backlog+0x1e3/0x650
|
|
__napi_poll+0xa6/0x500
|
|
net_rx_action+0x740/0xbb0
|
|
__do_softirq+0x183/0x5a4
|
|
|
|
The buggy address belongs to the object at ffff888485950880
|
|
which belongs to the cache kmalloc-64 of size 64
|
|
The buggy address is located 0 bytes inside of
|
|
64-byte region [ffff888485950880, ffff8884859508c0)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
|
|
flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
|
|
page_type: 0xffffffff()
|
|
raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
|
|
raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffff888485950780: fa fb fb
|
|
---truncated---(CVE-2024-26782)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: mmci: stm32: fix DMA API overlapping mappings warning
|
|
|
|
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
|
|
|
|
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
|
|
overlapping mappings aren't supported
|
|
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
|
|
add_dma_entry+0x234/0x2f4
|
|
Modules linked in:
|
|
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
|
|
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
|
|
Workqueue: events_freezable mmc_rescan
|
|
Call trace:
|
|
add_dma_entry+0x234/0x2f4
|
|
debug_dma_map_sg+0x198/0x350
|
|
__dma_map_sg_attrs+0xa0/0x110
|
|
dma_map_sg_attrs+0x10/0x2c
|
|
sdmmc_idma_prep_data+0x80/0xc0
|
|
mmci_prep_data+0x38/0x84
|
|
mmci_start_data+0x108/0x2dc
|
|
mmci_request+0xe4/0x190
|
|
__mmc_start_request+0x68/0x140
|
|
mmc_start_request+0x94/0xc0
|
|
mmc_wait_for_req+0x70/0x100
|
|
mmc_send_tuning+0x108/0x1ac
|
|
sdmmc_execute_tuning+0x14c/0x210
|
|
mmc_execute_tuning+0x48/0xec
|
|
mmc_sd_init_uhs_card.part.0+0x208/0x464
|
|
mmc_sd_init_card+0x318/0x89c
|
|
mmc_attach_sd+0xe4/0x180
|
|
mmc_rescan+0x244/0x320
|
|
|
|
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
|
|
dma_unmap_sg are not correctly balanced.
|
|
|
|
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
|
|
function is called and as this API is not managed on stm32 variant,
|
|
dma_unmap_sg is never called in this error path.(CVE-2024-26787)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
|
|
|
|
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
|
|
event is reported, otherwise a stale reference to netdevice remains in
|
|
the hook list.(CVE-2024-26808)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_set_pipapo: release elements in clone only from destroy path
|
|
|
|
Clone already always provides a current view of the lookup table, use it
|
|
to destroy the set, otherwise it is possible to destroy elements twice.
|
|
|
|
This fix requires:
|
|
|
|
212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
|
|
|
|
which came after:
|
|
|
|
9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").(CVE-2024-26809)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
|
|
|
|
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
|
|
that are out of bounds for their data type.
|
|
|
|
vmlinux get_bitmap(b=75) + 712
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:0>
|
|
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:592>
|
|
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:576>
|
|
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux DecodeRasMessage() + 304
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:833>
|
|
vmlinux ras_help() + 684
|
|
<net/netfilter/nf_conntrack_h323_main.c:1728>
|
|
vmlinux nf_confirm() + 188
|
|
<net/netfilter/nf_conntrack_proto.c:137>
|
|
|
|
Due to abnormal data in skb->data, the extension bitmap length
|
|
exceeds 32 when decoding ras message then uses the length to make
|
|
a shift operation. It will change into negative after several loop.
|
|
UBSAN load could detect a negative shift as an undefined behaviour
|
|
and reports exception.
|
|
So we add the protection to avoid the length exceeding 32. Or else
|
|
it will return out of range error and stop decoding.(CVE-2024-26851)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hns3: fix kernel crash when 1588 is received on HIP08 devices
|
|
|
|
The HIP08 devices does not register the ptp devices, so the
|
|
hdev->ptp is NULL, but the hardware can receive 1588 messages,
|
|
and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
|
|
access of hdev->ptp->flags will cause a kernel crash:
|
|
|
|
[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
|
|
[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
|
|
...
|
|
[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
|
|
[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
|
|
[ 5889.279101] sp : ffff800012c3bc50
|
|
[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
|
|
[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
|
|
[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
|
|
[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
|
|
[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
|
|
[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
|
|
[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
|
|
[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
|
|
[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
|
|
[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
|
|
[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
|
|
[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
|
|
[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
|
|
[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
|
|
[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
|
|
[ 5889.378857] Call trace:
|
|
[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
|
|
[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
|
|
[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
|
|
[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
|
|
[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
|
|
[ 5889.411084] napi_poll+0xcc/0x264
|
|
[ 5889.415329] net_rx_action+0xd4/0x21c
|
|
[ 5889.419911] __do_softirq+0x130/0x358
|
|
[ 5889.424484] irq_exit+0x134/0x154
|
|
[ 5889.428700] __handle_domain_irq+0x88/0xf0
|
|
[ 5889.433684] gic_handle_irq+0x78/0x2c0
|
|
[ 5889.438319] el1_irq+0xb8/0x140
|
|
[ 5889.442354] arch_cpu_idle+0x18/0x40
|
|
[ 5889.446816] default_idle_call+0x5c/0x1c0
|
|
[ 5889.451714] cpuidle_idle_call+0x174/0x1b0
|
|
[ 5889.456692] do_idle+0xc8/0x160
|
|
[ 5889.460717] cpu_startup_entry+0x30/0xfc
|
|
[ 5889.465523] secondary_start_kernel+0x158/0x1ec
|
|
[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
|
|
[ 5889.477950] SMP: stopping secondary CPUs
|
|
[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
|
|
[ 5890.522951] Starting crashdump kernel...(CVE-2024-26881)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md: fix kmemleak of rdev->serial
|
|
|
|
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
|
|
alloc not be freed, and kmemleak occurs.
|
|
|
|
unreferenced object 0xffff88815a350000 (size 49152):
|
|
comm "mdadm", pid 789, jiffies 4294716910
|
|
hex dump (first 32 bytes):
|
|
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 00 ................
|
|
backtrace (crc f773277a):
|
|
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
|
|
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
|
|
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
|
|
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
|
|
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
|
|
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
|
|
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
|
|
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
|
|
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
|
|
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
|
|
[<0000000085086a11>] vfs_ioctl+0x22/0x60
|
|
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
|
|
[<00000000e54e675e>] do_syscall_64+0x71/0x150
|
|
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74(CVE-2024-26900)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
|
|
|
|
syzbot identified a kernel information leak vulnerability in
|
|
do_sys_name_to_handle() and issued the following report [1].
|
|
|
|
[1]
|
|
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
do_sys_name_to_handle fs/fhandle.c:73 [inline]
|
|
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
|
|
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
|
|
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
|
|
...
|
|
|
|
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+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
|
|
kmalloc include/linux/slab.h:604 [inline]
|
|
do_sys_name_to_handle fs/fhandle.c:39 [inline]
|
|
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
|
|
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
|
|
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
|
|
...
|
|
|
|
Bytes 18-19 of 20 are uninitialized
|
|
Memory access of size 20 starts at ffff888128a46380
|
|
Data copied to user address 0000000020000240"
|
|
|
|
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
|
|
solve the problem.(CVE-2024-26901)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
|
|
|
|
During our fuzz testing of the connection and disconnection process at the
|
|
RFCOMM layer, we discovered this bug. By comparing the packets from a
|
|
normal connection and disconnection process with the testcase that
|
|
triggered a KASAN report. We analyzed the cause of this bug as follows:
|
|
|
|
1. In the packets captured during a normal connection, the host sends a
|
|
`Read Encryption Key Size` type of `HCI_CMD` packet
|
|
(Command Opcode: 0x1408) to the controller to inquire the length of
|
|
encryption key.After receiving this packet, the controller immediately
|
|
replies with a Command Completepacket (Event Code: 0x0e) to return the
|
|
Encryption Key Size.
|
|
|
|
2. In our fuzz test case, the timing of the controller's response to this
|
|
packet was delayed to an unexpected point: after the RFCOMM and L2CAP
|
|
layers had disconnected but before the HCI layer had disconnected.
|
|
|
|
3. After receiving the Encryption Key Size Response at the time described
|
|
in point 2, the host still called the rfcomm_check_security function.
|
|
However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`
|
|
had already been released, and when the function executed
|
|
`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,
|
|
specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.
|
|
|
|
To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling
|
|
rfcomm_recv_frame in rfcomm_process_rx.(CVE-2024-26903)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
|
|
|
|
------------[ cut here ]------------
|
|
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
|
|
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
|
|
[last unloaded: mlx_compat(OE)]
|
|
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
|
|
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
|
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
|
|
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
|
|
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
|
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
|
|
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
|
|
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
? show_regs+0x72/0x90
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? __warn+0x8d/0x160
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
? report_bug+0x1bb/0x1d0
|
|
? handle_bug+0x46/0x90
|
|
? exc_invalid_op+0x19/0x80
|
|
? asm_exc_invalid_op+0x1b/0x20
|
|
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
|
|
mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
|
|
ipoib_send+0x2ec/0x770 [ib_ipoib]
|
|
ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
|
|
dev_hard_start_xmit+0x8e/0x1e0
|
|
? validate_xmit_skb_list+0x4d/0x80
|
|
sch_direct_xmit+0x116/0x3a0
|
|
__dev_xmit_skb+0x1fd/0x580
|
|
__dev_queue_xmit+0x284/0x6b0
|
|
? _raw_spin_unlock_irq+0xe/0x50
|
|
? __flush_work.isra.0+0x20d/0x370
|
|
? push_pseudo_header+0x17/0x40 [ib_ipoib]
|
|
neigh_connected_output+0xcd/0x110
|
|
ip_finish_output2+0x179/0x480
|
|
? __smp_call_single_queue+0x61/0xa0
|
|
__ip_finish_output+0xc3/0x190
|
|
ip_finish_output+0x2e/0xf0
|
|
ip_output+0x78/0x110
|
|
? __pfx_ip_finish_output+0x10/0x10
|
|
ip_local_out+0x64/0x70
|
|
__ip_queue_xmit+0x18a/0x460
|
|
ip_queue_xmit+0x15/0x30
|
|
__tcp_transmit_skb+0x914/0x9c0
|
|
tcp_write_xmit+0x334/0x8d0
|
|
tcp_push_one+0x3c/0x60
|
|
tcp_sendmsg_locked+0x2e1/0xac0
|
|
tcp_sendmsg+0x2d/0x50
|
|
inet_sendmsg+0x43/0x90
|
|
sock_sendmsg+0x68/0x80
|
|
sock_write_iter+0x93/0x100
|
|
vfs_write+0x326/0x3c0
|
|
ksys_write+0xbd/0xf0
|
|
? do_syscall_64+0x69/0x90
|
|
__x64_sys_write+0x19/0x30
|
|
do_syscall_
|
|
---truncated---(CVE-2024-26907)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
|
|
|
|
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27395)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: gtp: Fix Use-After-Free in gtp_dellink
|
|
|
|
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of gtp_dellink, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27396)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
|
|
|
|
When running an XDP program that is attached to a cpumap entry, we don't
|
|
initialise the xdp_rxq_info data structure being used in the xdp_buff
|
|
that backs the XDP program invocation. Tobias noticed that this leads to
|
|
random values being returned as the xdp_md->rx_queue_index value for XDP
|
|
programs running in a cpumap.
|
|
|
|
This means we're basically returning the contents of the uninitialised
|
|
memory, which is bad. Fix this by zero-initialising the rxq data
|
|
structure before running the XDP program.(CVE-2024-27431)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS.
|
|
|
|
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-1647</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48632</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48659</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48660</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52609</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-52616</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52618</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-52621</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-52630</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52633</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-52639</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-52655</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52675</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52676</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24860</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26610</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26633</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26635</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26636</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26640</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26641</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-26661</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26665</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-26669</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-26680</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26684</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-26689</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-26702</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26706</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26707</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26712</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-26734</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-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-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-26776</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26782</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26787</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-26801</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-26808</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26809</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26811</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-26828</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26851</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26881</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26900</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26901</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26903</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26907</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26908</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27395</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27396</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27431</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48632</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48659</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48660</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52609</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52615</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52616</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52620</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52621</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-52630</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52633</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-52639</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52644</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52655</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52675</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52676</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24860</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26610</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26635</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26636</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26640</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26641</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-26661</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26665</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26668</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26669</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-26680</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26684</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-26689</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26697</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26702</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26706</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26707</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26712</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-26734</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26735</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-26754</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26763</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26776</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26782</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26787</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26801</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26808</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26809</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26811</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26812</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26828</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26851</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26881</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26900</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26901</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26903</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26907</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26908</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27395</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27396</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27431</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.138.0.165.oe2203.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.138.0.165.oe2203.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.138.0.165.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.138.0.165" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.138.0.165.oe2203.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:
|
|
|
|
i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()
|
|
|
|
memcpy() is called in a loop while 'operation->length' upper bound
|
|
is not checked and 'data_idx' also increments.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2022-48632</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
mm/slub: fix to return errno if kmalloc() fails
|
|
|
|
In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
|
|
out-of-memory, if it fails, return errno correctly rather than
|
|
triggering panic via BUG_ON();
|
|
|
|
kernel BUG at mm/slub.c:5893!
|
|
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
|
|
|
|
Call trace:
|
|
sysfs_slab_add+0x258/0x260 mm/slub.c:5973
|
|
__kmem_cache_create+0x60/0x118 mm/slub.c:4899
|
|
create_cache mm/slab_common.c:229 [inline]
|
|
kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
|
|
kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
|
|
f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
|
|
f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
|
|
f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
|
|
mount_bdev+0x1b8/0x210 fs/super.c:1400
|
|
f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
|
|
legacy_get_tree+0x30/0x74 fs/fs_context.c:610
|
|
vfs_get_tree+0x40/0x140 fs/super.c:1530
|
|
do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
|
|
path_mount+0x358/0x914 fs/namespace.c:3370
|
|
do_mount fs/namespace.c:3383 [inline]
|
|
__do_sys_mount fs/namespace.c:3591 [inline]
|
|
__se_sys_mount fs/namespace.c:3568 [inline]
|
|
__arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2022-48659</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:gpiolib: cdev: Set lineevent_state::irq after IRQ register successfullyWhen running gpio test on nxp-ls1028 platform with below commandgpiomon --num-events=3 --rising-edge gpiochip1 25There will be a warning trace as below:Call trace:free_irq+0x204/0x360lineevent_free+0x64/0x70gpio_ioctl+0x598/0x6a0__arm64_sys_ioctl+0xb4/0x100invoke_syscall+0x5c/0x130......el0t_64_sync+0x1a0/0x1a4The reason of this issue is that calling request_threaded_irq()function failed, and then lineevent_free() is invoked to releasethe resource. Since the lineevent_state::irq was already set, sothe subsequent invocation of free_irq() would trigger the abovewarning call trace. To fix this issue, set the lineevent_state::irqafter the IRQ register successfully.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2022-48660</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
binder: fix race between mmput() and do_exit()
|
|
|
|
Task A calls binder_update_page_range() to allocate and insert pages on
|
|
a remote address space from Task B. For this, Task A pins the remote mm
|
|
via mmget_not_zero() first. This can race with Task B do_exit() and the
|
|
final mmput() refcount decrement will come from Task A.
|
|
|
|
Task A | Task B
|
|
------------------+------------------
|
|
mmget_not_zero() |
|
|
| do_exit()
|
|
| exit_mm()
|
|
| mmput()
|
|
mmput() |
|
|
exit_mmap() |
|
|
remove_vma() |
|
|
fput() |
|
|
|
|
In this case, the work of ____fput() from Task B is queued up in Task A
|
|
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
|
|
work gets executed. However, Task A instead sleep, waiting for a reply
|
|
from Task B that never comes (it's dead).
|
|
|
|
This means the binder_deferred_release() is blocked until an unrelated
|
|
binder event forces Task A to go back to userspace. All the associated
|
|
death notifications will also be delayed until then.
|
|
|
|
In order to fix this use mmput_async() that will schedule the work in
|
|
the corresponding mm->async_put_work WQ instead of Task A.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52609</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52615</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
|
|
|
|
When the mpi_ec_ctx structure is initialized, some fields are not
|
|
cleared, causing a crash when referencing the field when the
|
|
structure was released. Initially, this issue was ignored because
|
|
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
|
|
For example, this error will be triggered when calculating the
|
|
Za value for SM2 separately.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52616</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
block/rnbd-srv: Check for unlikely string overflow
|
|
|
|
Since "dev_search_path" can technically be as large as PATH_MAX,
|
|
there was a risk of truncation when copying it and a second string
|
|
into "full_path" since it was also PATH_MAX sized. The W=1 builds were
|
|
reporting this warning:
|
|
|
|
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
|
|
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~
|
|
In function 'rnbd_srv_get_full_path',
|
|
inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
617 | dev_search_path, dev_name);
|
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fix this, unconditionally check for truncation (as was already done
|
|
for the case where "%SESSNAME%" was present).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52618</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52620</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
|
|
|
|
These three bpf_map_{lookup,update,delete}_elem() helpers are also
|
|
available for sleepable bpf program, so add the corresponding lock
|
|
assertion for sleepable bpf program, otherwise the following warning
|
|
will be reported when a sleepable bpf program manipulates bpf map under
|
|
interpreter mode (aka bpf_jit_enable=0):
|
|
|
|
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
|
|
CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
|
|
RIP: 0010:bpf_map_lookup_elem+0x54/0x60
|
|
......
|
|
Call Trace:
|
|
<TASK>
|
|
? __warn+0xa5/0x240
|
|
? bpf_map_lookup_elem+0x54/0x60
|
|
? report_bug+0x1ba/0x1f0
|
|
? handle_bug+0x40/0x80
|
|
? exc_invalid_op+0x18/0x50
|
|
? asm_exc_invalid_op+0x1b/0x20
|
|
? __pfx_bpf_map_lookup_elem+0x10/0x10
|
|
? rcu_lockdep_current_cpu_online+0x65/0xb0
|
|
? rcu_is_watching+0x23/0x50
|
|
? bpf_map_lookup_elem+0x54/0x60
|
|
? __pfx_bpf_map_lookup_elem+0x10/0x10
|
|
___bpf_prog_run+0x513/0x3b70
|
|
__bpf_prog_run32+0x9d/0xd0
|
|
? __bpf_prog_enter_sleepable_recur+0xad/0x120
|
|
? __bpf_prog_enter_sleepable_recur+0x3e/0x120
|
|
bpf_trampoline_6442580665+0x4d/0x1000
|
|
__x64_sys_getpgid+0x5/0x30
|
|
? do_syscall_64+0x36/0xb0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52621</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52623</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52629</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52630</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
um: time-travel: fix time corruption
|
|
|
|
In 'basic' time-travel mode (without =inf-cpu or =ext), we
|
|
still get timer interrupts. These can happen at arbitrary
|
|
points in time, i.e. while in timer_read(), which pushes
|
|
time forward just a little bit. Then, if we happen to get
|
|
the interrupt after calculating the new time to push to,
|
|
but before actually finishing that, the interrupt will set
|
|
the time to a value that's incompatible with the forward,
|
|
and we'll crash because time goes backwards when we do the
|
|
forwarding.
|
|
|
|
Fix this by reading the time_travel_time, calculating the
|
|
adjustment, and doing the adjustment all with interrupts
|
|
disabled.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52633</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52635</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52637</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52639</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: 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-24</ReleaseDate>
|
|
<CVE>CVE-2023-52644</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
usb: aqc111: check packet for fixup for true limit
|
|
|
|
If a device sends a packet that is inbetween 0
|
|
and sizeof(u64) the value passed to skb_trim()
|
|
as length will wrap around ending up as some very
|
|
large value.
|
|
|
|
The driver will then proceed to parse the header
|
|
located at that position, which will either oops or
|
|
process some random value.
|
|
|
|
The fix is to check against sizeof(u64) rather than
|
|
0, which the driver currently does. The issue exists
|
|
since the introduction of the driver.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52655</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52675</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
bpf: Guard stack limits against 32bit overflow
|
|
|
|
This patch promotes the arithmetic around checking stack bounds to be
|
|
done in the 64-bit domain, instead of the current 32bit. The arithmetic
|
|
implies adding together a 64-bit register with a int offset. The
|
|
register was checked to be below 1<<29 when it was variable, but not
|
|
when it was fixed. The offset either comes from an instruction (in which
|
|
case it is 16 bit), from another register (in which case the caller
|
|
checked it to be below 1<<29 [1]), or from the size of an argument to a
|
|
kfunc (in which case it can be a u32 [2]). Between the register being
|
|
inconsistently checked to be below 1<<29, and the offset being up to an
|
|
u32, it appears that we were open to overflowing the `int`s which were
|
|
currently used for arithmetic.
|
|
|
|
[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498
|
|
[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52676</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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">A race condition was found in the Linux kernel s bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-24860</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
wifi: iwlwifi: fix a memory corruption
|
|
|
|
iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
|
|
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
|
|
bytes, we'll write past the buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26610</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__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]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
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:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__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]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
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_sendms
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26633</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
llc: Drop support for ETH_P_TR_802_2.
|
|
|
|
syzbot reported an uninit-value bug below. [0]
|
|
|
|
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
|
|
(0x0011), and syzbot abused the latter to trigger the bug.
|
|
|
|
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
|
|
|
|
llc_conn_handler() initialises local variables {saddr,daddr}.mac
|
|
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
|
|
them to __llc_lookup().
|
|
|
|
However, the initialisation is done only when skb->protocol is
|
|
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
|
|
__llc_lookup_listener() will read garbage.
|
|
|
|
The missing initialisation existed prior to commit 211ed865108e
|
|
("net: delete all instances of special processing for token ring").
|
|
|
|
It removed the part to kick out the token ring stuff but forgot to
|
|
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
|
|
|
|
Let's remove llc_tr_packet_type and complete the deprecation.
|
|
|
|
[0]:
|
|
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup net/llc/llc_conn.c:611 [inline]
|
|
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
|
|
netif_receive_skb_internal net/core/dev.c:5727 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x1490 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Local variable daddr created at:
|
|
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
|
|
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26635</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
llc: make llc_ui_sendmsg() more robust against bonding changes
|
|
|
|
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
|
|
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
|
|
|
|
Like some others, llc_ui_sendmsg() releases the socket lock before
|
|
calling sock_alloc_send_skb().
|
|
Then it acquires it again, but does not redo all the sanity checks
|
|
that were performed.
|
|
|
|
This fix:
|
|
|
|
- Uses LL_RESERVED_SPACE() to reserve space.
|
|
- Check all conditions again after socket lock is held again.
|
|
- Do not account Ethernet header for mtu limitation.
|
|
|
|
[1]
|
|
|
|
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
|
|
|
|
kernel BUG at net/core/skbuff.c:193 !
|
|
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in:
|
|
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : skb_panic net/core/skbuff.c:189 [inline]
|
|
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
lr : skb_panic net/core/skbuff.c:189 [inline]
|
|
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
sp : ffff800096f97000
|
|
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
|
|
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
|
|
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
|
|
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
|
|
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
|
|
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
|
|
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
|
|
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
|
|
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
|
|
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
|
|
Call trace:
|
|
skb_panic net/core/skbuff.c:189 [inline]
|
|
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
skb_push+0xf0/0x108 net/core/skbuff.c:2451
|
|
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
|
|
dev_hard_header include/linux/netdevice.h:3188 [inline]
|
|
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
|
|
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
|
|
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
|
|
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
|
|
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
|
|
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
|
|
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_sendmsg+0x194/0x274 net/socket.c:767
|
|
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
|
|
do_splice_from fs/splice.c:933 [inline]
|
|
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
|
|
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
|
|
do_splice_direct+0x20c/0x348 fs/splice.c:1194
|
|
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
|
|
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
|
|
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
|
|
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
|
|
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
|
|
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
|
|
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
|
|
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
|
|
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
|
|
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
|
|
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
|
|
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26636</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
tcp: add sanity checks to rx zerocopy
|
|
|
|
TCP rx zerocopy intent is to map pages initially allocated
|
|
from NIC drivers, not pages owned by a fs.
|
|
|
|
This patch adds to can_map_frag() these additional checks:
|
|
|
|
- Page must not be a compound one.
|
|
- page->mapping must be NULL.
|
|
|
|
This fixes the panic reported by ZhangPeng.
|
|
|
|
syzbot was able to loopback packets built with sendfile(),
|
|
mapping pages owned by an ext4 file to TCP rx zerocopy.
|
|
|
|
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
|
|
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
|
|
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
|
|
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)
|
|
fallocate(r5, 0x0, 0x0, 0x85b8)
|
|
sendfile(r4, r5, 0x0, 0x8ba0)
|
|
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
|
|
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
|
|
0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
|
|
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26640</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
|
|
|
|
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
|
|
|
|
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
|
|
variable after this call as it can change skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
|
|
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
|
|
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
|
|
gre_rcv+0x143f/0x1870
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
|
|
netif_receive_skb_internal net/core/dev.c:5732 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
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
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
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: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26641</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26642</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26645</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
|
|
|
|
In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"
|
|
pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to
|
|
ensure the tg is not NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26661</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
tunnels: fix out of bounds access when building IPv6 PMTU error
|
|
|
|
If the ICMPv6 error is built from a non-linear skb we get the following
|
|
splat,
|
|
|
|
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
|
|
Read of size 4 at addr ffff88811d402c80 by task netperf/820
|
|
CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
|
|
...
|
|
kasan_report+0xd8/0x110
|
|
do_csum+0x220/0x240
|
|
csum_partial+0xc/0x20
|
|
skb_tunnel_check_pmtu+0xeb9/0x3280
|
|
vxlan_xmit_one+0x14c2/0x4080
|
|
vxlan_xmit+0xf61/0x5c00
|
|
dev_hard_start_xmit+0xfb/0x510
|
|
__dev_queue_xmit+0x7cd/0x32a0
|
|
br_dev_queue_push_xmit+0x39d/0x6a0
|
|
|
|
Use skb_checksum instead of csum_partial who cannot deal with non-linear
|
|
SKBs.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26665</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26668</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26669</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26675</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26679</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26680</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
|
|
|
|
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
|
|
XGMAC core") checks and reports safety errors, but leaves the
|
|
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
|
|
a storm of interrupt.
|
|
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26684</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26685</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26686</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26689</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26697</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
|
|
|
|
Recently, we encounter kernel crash in function rm3100_common_probe
|
|
caused by out of bound access of array rm3100_samp_rates (because of
|
|
underlying hardware failures). Add boundary check to prevent out of
|
|
bound access.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26702</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
parisc: Fix random data corruption from exception handler
|
|
|
|
The current exception handler implementation, which assists when accessing
|
|
user space memory, may exhibit random data corruption if the compiler decides
|
|
to use a different register than the specified register %r29 (defined in
|
|
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
|
|
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
|
|
trash whatever this register is used for.
|
|
Looking at the assembly I found that this happens sometimes in emulate_ldd().
|
|
|
|
To solve the issue, the easiest solution would be if it somehow is
|
|
possible to tell the fault handler which register is used to hold the error
|
|
code. Using %0 or %1 in the inline assembly is not posssible as it will show
|
|
up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not
|
|
convert to an integer.
|
|
|
|
This patch takes another, better and more flexible approach:
|
|
We extend the __ex_table (which is out of the execution path) by one 32-word.
|
|
In this word we tell the compiler to insert the assembler instruction
|
|
"or %r0,%r0,%reg", where %reg references the register which the compiler
|
|
choosed for the error return code.
|
|
In case of an access failure, the fault handler finds the __ex_table entry and
|
|
can examine the opcode. The used register is encoded in the lowest 5 bits, and
|
|
the fault handler can then store -EFAULT into this register.
|
|
|
|
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
|
|
config option any longer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26706</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
|
|
|
|
Syzkaller reported [1] hitting a warning after failing to allocate
|
|
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
|
|
not help much in this case, it might be prudent to switch to
|
|
netdev_warn_once(). At the very least it will suppress syzkaller
|
|
reports such as [1].
|
|
|
|
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
|
|
for similar reasons.
|
|
|
|
[1]
|
|
HSR: Could not send supervision frame
|
|
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
|
|
...
|
|
Call Trace:
|
|
<IRQ>
|
|
hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
|
|
call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
|
|
expire_timers kernel/time/timer.c:1751 [inline]
|
|
__run_timers+0x764/0xb20 kernel/time/timer.c:2022
|
|
run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
invoke_softirq kernel/softirq.c:427 [inline]
|
|
__irq_exit_rcu kernel/softirq.c:632 [inline]
|
|
irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
|
|
sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
|
|
...
|
|
|
|
This issue is also found in older kernels (at least up to 5.10).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26707</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
powerpc/kasan: Fix addr error caused by page alignment
|
|
|
|
In kasan_init_region, when k_start is not page aligned, at the begin of
|
|
for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
|
|
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
|
|
because the memory address space from va to block is not alloced by
|
|
memblock_alloc, which will not be reserved by memblock_reserve later, it
|
|
will be used by other places.
|
|
|
|
As a result, memory overwriting occurs.
|
|
|
|
for example:
|
|
int __init __weak kasan_init_region(void *start, size_t size)
|
|
{
|
|
[...]
|
|
/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
|
|
block = memblock_alloc(k_end - k_start, PAGE_SIZE);
|
|
[...]
|
|
for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
|
|
/* at the begin of for loop
|
|
* block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
|
|
* va(dcd96c00) is less than block(dcd97000), va is invalid
|
|
*/
|
|
void *va = block + k_cur - k_start;
|
|
[...]
|
|
}
|
|
[...]
|
|
}
|
|
|
|
Therefore, page alignment is performed on k_start before
|
|
memblock_alloc() to ensure the validity of the VA address.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26712</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26720</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26726</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26733</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
devlink: fix possible use-after-free and memory leaks in devlink_init()
|
|
|
|
The pernet operations structure for the subsystem must be registered
|
|
before registering the generic netlink family.
|
|
|
|
Make an unregister in case of unsuccessful registration.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26734</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26735</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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/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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26740</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26743</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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: 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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26744</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26754</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26763</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
|
|
|
|
Return IRQ_NONE from the interrupt handler when no interrupt was
|
|
detected. Because an empty interrupt will cause a null pointer error:
|
|
|
|
Unable to handle kernel NULL pointer dereference at virtual
|
|
address 0000000000000008
|
|
Call trace:
|
|
complete+0x54/0x100
|
|
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
|
|
__handle_irq_event_percpu+0x64/0x1e0
|
|
handle_irq_event+0x7c/0x1cc</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26776</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
mptcp: fix double-free on socket dismantle
|
|
|
|
when MPTCP server accepts an incoming connection, it clones its listener
|
|
socket. However, the pointer to 'inet_opt' for the new socket has the same
|
|
value as the original one: as a consequence, on program exit it's possible
|
|
to observe the following splat:
|
|
|
|
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
|
|
Free of addr ffff888485950880 by task swapper/25/0
|
|
|
|
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
|
|
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
|
|
Call Trace:
|
|
<IRQ>
|
|
dump_stack_lvl+0x32/0x50
|
|
print_report+0xca/0x620
|
|
kasan_report_invalid_free+0x64/0x90
|
|
__kasan_slab_free+0x1aa/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
rcu_do_batch+0x34e/0xd90
|
|
rcu_core+0x559/0xac0
|
|
__do_softirq+0x183/0x5a4
|
|
irq_exit_rcu+0x12d/0x170
|
|
sysvec_apic_timer_interrupt+0x6b/0x80
|
|
</IRQ>
|
|
<TASK>
|
|
asm_sysvec_apic_timer_interrupt+0x16/0x20
|
|
RIP: 0010:cpuidle_enter_state+0x175/0x300
|
|
Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b
|
|
RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
|
|
RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
|
|
RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
|
|
RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
|
|
R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
|
|
R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
|
|
cpuidle_enter+0x4a/0xa0
|
|
do_idle+0x310/0x410
|
|
cpu_startup_entry+0x51/0x60
|
|
start_secondary+0x211/0x270
|
|
secondary_startup_64_no_verify+0x184/0x18b
|
|
</TASK>
|
|
|
|
Allocated by task 6853:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
__kasan_kmalloc+0xa6/0xb0
|
|
__kmalloc+0x1eb/0x450
|
|
cipso_v4_sock_setattr+0x96/0x360
|
|
netlbl_sock_setattr+0x132/0x1f0
|
|
selinux_netlbl_socket_post_create+0x6c/0x110
|
|
selinux_socket_post_create+0x37b/0x7f0
|
|
security_socket_post_create+0x63/0xb0
|
|
__sock_create+0x305/0x450
|
|
__sys_socket_create.part.23+0xbd/0x130
|
|
__sys_socket+0x37/0xb0
|
|
__x64_sys_socket+0x6f/0xb0
|
|
do_syscall_64+0x83/0x160
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Freed by task 6858:
|
|
kasan_save_stack+0x1c/0x40
|
|
kasan_save_track+0x10/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
__kasan_slab_free+0x12c/0x1f0
|
|
kfree+0xed/0x2e0
|
|
inet_sock_destruct+0x54f/0x8b0
|
|
__sk_destruct+0x48/0x5b0
|
|
subflow_ulp_release+0x1f0/0x250
|
|
tcp_cleanup_ulp+0x6e/0x110
|
|
tcp_v4_destroy_sock+0x5a/0x3a0
|
|
inet_csk_destroy_sock+0x135/0x390
|
|
tcp_fin+0x416/0x5c0
|
|
tcp_data_queue+0x1bc8/0x4310
|
|
tcp_rcv_state_process+0x15a3/0x47b0
|
|
tcp_v4_do_rcv+0x2c1/0x990
|
|
tcp_v4_rcv+0x41fb/0x5ed0
|
|
ip_protocol_deliver_rcu+0x6d/0x9f0
|
|
ip_local_deliver_finish+0x278/0x360
|
|
ip_local_deliver+0x182/0x2c0
|
|
ip_rcv+0xb5/0x1c0
|
|
__netif_receive_skb_one_core+0x16e/0x1b0
|
|
process_backlog+0x1e3/0x650
|
|
__napi_poll+0xa6/0x500
|
|
net_rx_action+0x740/0xbb0
|
|
__do_softirq+0x183/0x5a4
|
|
|
|
The buggy address belongs to the object at ffff888485950880
|
|
which belongs to the cache kmalloc-64 of size 64
|
|
The buggy address is located 0 bytes inside of
|
|
64-byte region [ffff888485950880, ffff8884859508c0)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
|
|
flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
|
|
page_type: 0xffffffff()
|
|
raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
|
|
raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffff888485950780: fa fb fb
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26782</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
mmc: mmci: stm32: fix DMA API overlapping mappings warning
|
|
|
|
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
|
|
|
|
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
|
|
overlapping mappings aren't supported
|
|
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
|
|
add_dma_entry+0x234/0x2f4
|
|
Modules linked in:
|
|
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
|
|
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
|
|
Workqueue: events_freezable mmc_rescan
|
|
Call trace:
|
|
add_dma_entry+0x234/0x2f4
|
|
debug_dma_map_sg+0x198/0x350
|
|
__dma_map_sg_attrs+0xa0/0x110
|
|
dma_map_sg_attrs+0x10/0x2c
|
|
sdmmc_idma_prep_data+0x80/0xc0
|
|
mmci_prep_data+0x38/0x84
|
|
mmci_start_data+0x108/0x2dc
|
|
mmci_request+0xe4/0x190
|
|
__mmc_start_request+0x68/0x140
|
|
mmc_start_request+0x94/0xc0
|
|
mmc_wait_for_req+0x70/0x100
|
|
mmc_send_tuning+0x108/0x1ac
|
|
sdmmc_execute_tuning+0x14c/0x210
|
|
mmc_execute_tuning+0x48/0xec
|
|
mmc_sd_init_uhs_card.part.0+0x208/0x464
|
|
mmc_sd_init_card+0x318/0x89c
|
|
mmc_attach_sd+0xe4/0x180
|
|
mmc_rescan+0x244/0x320
|
|
|
|
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
|
|
dma_unmap_sg are not correctly balanced.
|
|
|
|
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
|
|
function is called and as this API is not managed on stm32 variant,
|
|
dma_unmap_sg is never called in this error path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26787</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26801</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26805</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</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:
|
|
|
|
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
|
|
|
|
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
|
|
event is reported, otherwise a stale reference to netdevice remains in
|
|
the hook list.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26808</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="64" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="64" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_set_pipapo: release elements in clone only from destroy path
|
|
|
|
Clone already always provides a current view of the lookup table, use it
|
|
to destroy the set, otherwise it is possible to destroy elements twice.
|
|
|
|
This fix requires:
|
|
|
|
212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
|
|
|
|
which came after:
|
|
|
|
9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26809</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="65" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="65" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26811</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="66" 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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26812</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="67" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="67" 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-24</ReleaseDate>
|
|
<CVE>CVE-2024-26828</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="68" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="68" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
|
|
|
|
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
|
|
that are out of bounds for their data type.
|
|
|
|
vmlinux get_bitmap(b=75) + 712
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:0>
|
|
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:592>
|
|
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:576>
|
|
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:814>
|
|
vmlinux DecodeRasMessage() + 304
|
|
<net/netfilter/nf_conntrack_h323_asn1.c:833>
|
|
vmlinux ras_help() + 684
|
|
<net/netfilter/nf_conntrack_h323_main.c:1728>
|
|
vmlinux nf_confirm() + 188
|
|
<net/netfilter/nf_conntrack_proto.c:137>
|
|
|
|
Due to abnormal data in skb->data, the extension bitmap length
|
|
exceeds 32 when decoding ras message then uses the length to make
|
|
a shift operation. It will change into negative after several loop.
|
|
UBSAN load could detect a negative shift as an undefined behaviour
|
|
and reports exception.
|
|
So we add the protection to avoid the length exceeding 32. Or else
|
|
it will return out of range error and stop decoding.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26851</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="69" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="69" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is received on HIP08 devicesThe HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL, but the hardware can receive 1588 messages,and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, theaccess of hdev->ptp->flags will cause a kernel crash:[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge][ 5889.279101] sp : ffff800012c3bc50[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080[ 5889.378857] Call trace:[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3][ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3][ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3][ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3][ 5889.411084] napi_poll+0xcc/0x264[ 5889.415329] net_rx_action+0xd4/0x21c[ 5889.419911] __do_softirq+0x130/0x358[ 5889.424484] irq_exit+0x134/0x154[ 5889.428700] __handle_domain_irq+0x88/0xf0[ 5889.433684] gic_handle_irq+0x78/0x2c0[ 5889.438319] el1_irq+0xb8/0x140[ 5889.442354] arch_cpu_idle+0x18/0x40[ 5889.446816] default_idle_call+0x5c/0x1c0[ 5889.451714] cpuidle_idle_call+0x174/0x1b0[ 5889.456692] do_idle+0xc8/0x160[ 5889.460717] cpu_startup_entry+0x30/0xfc[ 5889.465523] secondary_start_kernel+0x158/0x1ec[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)[ 5889.477950] SMP: stopping secondary CPUs[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95[ 5890.522951] Starting crashdump kernel...</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26881</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="70" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="70" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev->serialIf kobject_add() is fail in bind_rdev_to_array(), rdev->serial will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152): comm mdadm , pid 789, jiffies 4294716910 hex dump (first 32 bytes): 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 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26900</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="71" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="71" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...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+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Bytes 18-19 of 20 are uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240 Per Chuck Lever s suggestion, use kzalloc() instead of kmalloc() tosolve the problem.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26901</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="72" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="72" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_securityDuring our fuzz testing of the connection and disconnection process at theRFCOMM layer, we discovered this bug. By comparing the packets from anormal connection and disconnection process with the testcase thattriggered a KASAN report. We analyzed the cause of this bug as follows:1. In the packets captured during a normal connection, the host sends a`Read Encryption Key Size` type of `HCI_CMD` packet(Command Opcode: 0x1408) to the controller to inquire the length ofencryption key.After receiving this packet, the controller immediatelyreplies with a Command Completepacket (Event Code: 0x0e) to return theEncryption Key Size.2. In our fuzz test case, the timing of the controller s response to thispacket was delayed to an unexpected point: after the RFCOMM and L2CAPlayers had disconnected but before the HCI layer had disconnected.3. After receiving the Encryption Key Size Response at the time describedin point 2, the host still called the rfcomm_check_security function.However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`had already been released, and when the function executed`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.To fix this bug, check if `sk->sk_state` is BT_CLOSED before callingrfcomm_recv_frame in rfcomm_process_rx.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26903</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="73" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="73" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field eseg->inline_hdr.start at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26907</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="74" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="74" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26908</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="75" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="75" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
|
|
|
|
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27395</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="76" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="76" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: gtp: Fix Use-After-Free in gtp_dellink
|
|
|
|
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
|
|
of gtp_dellink, is not part of the RCU read critical section, it
|
|
is possible that the RCU grace period will pass during the traversal and
|
|
the key will be free.
|
|
|
|
To prevent this, it should be changed to hlist_for_each_entry_safe.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27396</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="77" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="77" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
|
|
|
|
When running an XDP program that is attached to a cpumap entry, we don't
|
|
initialise the xdp_rxq_info data structure being used in the xdp_buff
|
|
that backs the XDP program invocation. Tobias noticed that this leads to
|
|
random values being returned as the xdp_md->rx_queue_index value for XDP
|
|
programs running in a cpumap.
|
|
|
|
This means we're basically returning the contents of the uninitialised
|
|
memory, which is bad. Fix this by zero-initialising the rxq data
|
|
structure before running the XDP program.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27431</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1647</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |