2861 lines
129 KiB
XML
2861 lines
129 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-SP3</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-1650</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-SP3.</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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.(CVE-2023-52685)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/powernv: Add a null pointer check to scom_debug_init_one()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.
|
|
Add a null pointer check, and release 'ent' to avoid memory leaks.(CVE-2023-52690)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
|
|
|
|
With tpd12s015_remove() marked with __exit this function is discarded
|
|
when the driver is compiled as a built-in. The result is that when the
|
|
driver unbinds there is no cleanup done which results in resource
|
|
leakage or worse.(CVE-2023-52694)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
|
|
|
|
rx_data_reassembly skb is stored during NCI data exchange for processing
|
|
fragmented packets. It is dropped only when the last fragment is processed
|
|
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
|
|
However, the NCI device may be deallocated before that which leads to skb
|
|
leak.
|
|
|
|
As by design the rx_data_reassembly skb is bound to the NCI device and
|
|
nothing prevents the device to be freed before the skb is processed in
|
|
some way and cleaned, free it on the NCI device cleanup.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-26825)
|
|
|
|
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:
|
|
|
|
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)
|
|
|
|
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:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.(CVE-2024-26923)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: check offset alignment in binder_get_object()
|
|
|
|
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
|
|
txn") introduced changes to how binder objects are copied. In doing so,
|
|
it unintentionally removed an offset alignment check done through calls
|
|
to binder_alloc_copy_from_buffer() -> check_buffer().
|
|
|
|
These calls were replaced in binder_get_object() with copy_from_user(),
|
|
so now an explicit offset alignment check is needed here. This avoids
|
|
later complications when unwinding the objects gets harder.
|
|
|
|
It is worth noting this check existed prior to commit 7a67a39320df
|
|
("binder: add function to copy binder object from buffer"), likely
|
|
removed due to redundancy at the time.(CVE-2024-26926)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/i915/gt: Reset queue_priority_hint on parking
|
|
|
|
Originally, with strict in order execution, we could complete execution
|
|
only when the queue was empty. Preempt-to-busy allows replacement of an
|
|
active request that may complete before the preemption is processed by
|
|
HW. If that happens, the request is retired from the queue, but the
|
|
queue_priority_hint remains set, preventing direct submission until
|
|
after the next CS interrupt is processed.
|
|
|
|
This preempt-to-busy race can be triggered by the heartbeat, which will
|
|
also act as the power-management barrier and upon completion allow us to
|
|
idle the HW. We may process the completion of the heartbeat, and begin
|
|
parking the engine before the CS event that restores the
|
|
queue_priority_hint, causing us to fail the assertion that it is MIN.
|
|
|
|
<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
|
|
<0>[ 166.210781] Dumping ftrace buffer:
|
|
<0>[ 166.210795] ---------------------------------
|
|
...
|
|
<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
|
|
<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
|
|
<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
|
|
<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
|
|
<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
|
|
<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
|
|
<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
|
|
<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
|
|
<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
|
|
<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
|
|
<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
|
|
<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
|
|
<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
|
|
<0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
|
|
<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }
|
|
<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }
|
|
<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
|
|
<0>[ 167.303811] ---------------------------------
|
|
<4>[ 167.304722] ------------[ cut here ]------------
|
|
<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
|
|
<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
|
|
<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
|
|
<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]
|
|
<4>[ 16
|
|
---truncated---(CVE-2024-26937)
|
|
|
|
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:
|
|
|
|
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
|
|
|
|
When the sco connection is established and then, the sco socket
|
|
is releasing, timeout_work will be scheduled to judge whether
|
|
the sco disconnection is timeout. The sock will be deallocated
|
|
later, but it is dereferenced again in sco_sock_timeout. As a
|
|
result, the use-after-free bugs will happen. The root cause is
|
|
shown below:
|
|
|
|
Cleanup Thread | Worker Thread
|
|
sco_sock_release |
|
|
sco_sock_close |
|
|
__sco_sock_close |
|
|
sco_sock_set_timer |
|
|
schedule_delayed_work |
|
|
sco_sock_kill | (wait a time)
|
|
sock_put(sk) //FREE | sco_sock_timeout
|
|
| sock_hold(sk) //USE
|
|
|
|
The KASAN report triggered by POC is shown below:
|
|
|
|
[ 95.890016] ==================================================================
|
|
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
|
|
...
|
|
[ 95.890755] Workqueue: events sco_sock_timeout
|
|
[ 95.890755] Call Trace:
|
|
[ 95.890755] <TASK>
|
|
[ 95.890755] dump_stack_lvl+0x45/0x110
|
|
[ 95.890755] print_address_description+0x78/0x390
|
|
[ 95.890755] print_report+0x11b/0x250
|
|
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_report+0x139/0x170
|
|
[ 95.890755] ? update_load_avg+0xe5/0x9f0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_check_range+0x2c3/0x2e0
|
|
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] process_one_work+0x561/0xc50
|
|
[ 95.890755] worker_thread+0xab2/0x13c0
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] kthread+0x279/0x300
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork+0x34/0x60
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork_asm+0x11/0x20
|
|
[ 95.890755] </TASK>
|
|
[ 95.890755]
|
|
[ 95.890755] Allocated by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] __kasan_kmalloc+0x86/0x90
|
|
[ 95.890755] __kmalloc+0x17f/0x360
|
|
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
|
|
[ 95.890755] sk_alloc+0x31/0x4e0
|
|
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
|
|
[ 95.890755] sco_sock_create+0xad/0x320
|
|
[ 95.890755] bt_sock_create+0x145/0x320
|
|
[ 95.890755] __sock_create+0x2e1/0x650
|
|
[ 95.890755] __sys_socket+0xd0/0x280
|
|
[ 95.890755] __x64_sys_socket+0x75/0x80
|
|
[ 95.890755] do_syscall_64+0xc4/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] Freed by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] kasan_save_free_info+0x40/0x50
|
|
[ 95.890755] poison_slab_object+0x118/0x180
|
|
[ 95.890755] __kasan_slab_free+0x12/0x30
|
|
[ 95.890755] kfree+0xb2/0x240
|
|
[ 95.890755] __sk_destruct+0x317/0x410
|
|
[ 95.890755] sco_sock_release+0x232/0x280
|
|
[ 95.890755] sock_close+0xb2/0x210
|
|
[ 95.890755] __fput+0x37f/0x770
|
|
[ 95.890755] task_work_run+0x1ae/0x210
|
|
[ 95.890755] get_signal+0xe17/0xf70
|
|
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
|
|
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
|
|
[ 95.890755] do_syscall_64+0xd1/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
|
|
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 95.890755] The buggy address is located 128 bytes inside of
|
|
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the physical page:
|
|
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
|
|
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
|
|
[ 95.890755] ano
|
|
---truncated---(CVE-2024-27398)
|
|
|
|
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)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
|
|
|
|
Do the cache flush of converted pages in svm_register_enc_region() before
|
|
dropping kvm->lock to fix use-after-free issues where region and/or its
|
|
array of pages could be freed by a different task, e.g. if userspace has
|
|
__unregister_enc_region_locked() already queued up for the region.
|
|
|
|
Note, the "obvious" alternative of using local variables doesn't fully
|
|
resolve the bug, as region->pages is also dynamically allocated. I.e. the
|
|
region structure itself would be fine, but region->pages could be freed.
|
|
|
|
Flushing multiple pages under kvm->lock is unfortunate, but the entire
|
|
flow is a rare slow path, and the manual flush is only needed on CPUs that
|
|
lack coherency for encrypted memory.(CVE-2024-35791)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: dbg-tlv: ensure NUL termination
|
|
|
|
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
|
|
ensure the string is terminated correctly before using it.(CVE-2024-35845)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
|
|
|
|
devm_kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure. Ensure the allocation was successful
|
|
by checking the pointer validity.(CVE-2024-35943)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
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-1650</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<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-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-52635</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-2023-52685</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52690</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52694</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-26661</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-26686</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-26712</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26825</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-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-26908</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26923</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26926</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26937</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-27398</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27431</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35791</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35845</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35849</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35943</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52615</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-52635</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-2023-52685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52690</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52694</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26610</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26661</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26675</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26686</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26702</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26712</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26825</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26851</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-26908</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26923</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26926</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26937</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-27398</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27431</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35845</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35849</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35943</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-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-source-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-200.0.0.113.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-200.0.0.113.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-200.0.0.113.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-200.0.0.113" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-200.0.0.113.oe2203sp3.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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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">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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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: 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-SP3</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-1650</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:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52685</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
powerpc/powernv: Add a null pointer check to scom_debug_init_one()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.
|
|
Add a null pointer check, and release 'ent' to avoid memory leaks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52690</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
|
|
|
|
With tpd12s015_remove() marked with __exit this function is discarded
|
|
when the driver is compiled as a built-in. The result is that when the
|
|
driver unbinds there is no cleanup done which results in resource
|
|
leakage or worse.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2023-52694</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
|
|
|
|
rx_data_reassembly skb is stored during NCI data exchange for processing
|
|
fragmented packets. It is dropped only when the last fragment is processed
|
|
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
|
|
However, the NCI device may be deallocated before that which leads to skb
|
|
leak.
|
|
|
|
As by design the rx_data_reassembly skb is bound to the NCI device and
|
|
nothing prevents the device to be freed before the skb is processed in
|
|
some way and cleaned, free it on the NCI device cleanup.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26825</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector></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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: 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-SP3</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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved: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-SP3</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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved: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-SP3</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-1650</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: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-SP3</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-1650</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">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-SP3</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-1650</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:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26923</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-24</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1650</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:
|
|
|
|
binder: check offset alignment in binder_get_object()
|
|
|
|
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
|
|
txn") introduced changes to how binder objects are copied. In doing so,
|
|
it unintentionally removed an offset alignment check done through calls
|
|
to binder_alloc_copy_from_buffer() -> check_buffer().
|
|
|
|
These calls were replaced in binder_get_object() with copy_from_user(),
|
|
so now an explicit offset alignment check is needed here. This avoids
|
|
later complications when unwinding the objects gets harder.
|
|
|
|
It is worth noting this check existed prior to commit 7a67a39320df
|
|
("binder: add function to copy binder object from buffer"), likely
|
|
removed due to redundancy at the time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26926</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
drm/i915/gt: Reset queue_priority_hint on parking
|
|
|
|
Originally, with strict in order execution, we could complete execution
|
|
only when the queue was empty. Preempt-to-busy allows replacement of an
|
|
active request that may complete before the preemption is processed by
|
|
HW. If that happens, the request is retired from the queue, but the
|
|
queue_priority_hint remains set, preventing direct submission until
|
|
after the next CS interrupt is processed.
|
|
|
|
This preempt-to-busy race can be triggered by the heartbeat, which will
|
|
also act as the power-management barrier and upon completion allow us to
|
|
idle the HW. We may process the completion of the heartbeat, and begin
|
|
parking the engine before the CS event that restores the
|
|
queue_priority_hint, causing us to fail the assertion that it is MIN.
|
|
|
|
<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
|
|
<0>[ 166.210781] Dumping ftrace buffer:
|
|
<0>[ 166.210795] ---------------------------------
|
|
...
|
|
<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
|
|
<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
|
|
<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
|
|
<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
|
|
<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
|
|
<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
|
|
<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
|
|
<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
|
|
<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
|
|
<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
|
|
<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
|
|
<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
|
|
<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
|
|
<0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
|
|
<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }
|
|
<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }
|
|
<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
|
|
<0>[ 167.303811] ---------------------------------
|
|
<4>[ 167.304722] ------------[ cut here ]------------
|
|
<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
|
|
<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
|
|
<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
|
|
<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]
|
|
<4>[ 16
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-26937</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: 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-SP3</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-1650</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:
|
|
|
|
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
|
|
|
|
When the sco connection is established and then, the sco socket
|
|
is releasing, timeout_work will be scheduled to judge whether
|
|
the sco disconnection is timeout. The sock will be deallocated
|
|
later, but it is dereferenced again in sco_sock_timeout. As a
|
|
result, the use-after-free bugs will happen. The root cause is
|
|
shown below:
|
|
|
|
Cleanup Thread | Worker Thread
|
|
sco_sock_release |
|
|
sco_sock_close |
|
|
__sco_sock_close |
|
|
sco_sock_set_timer |
|
|
schedule_delayed_work |
|
|
sco_sock_kill | (wait a time)
|
|
sock_put(sk) //FREE | sco_sock_timeout
|
|
| sock_hold(sk) //USE
|
|
|
|
The KASAN report triggered by POC is shown below:
|
|
|
|
[ 95.890016] ==================================================================
|
|
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
|
|
...
|
|
[ 95.890755] Workqueue: events sco_sock_timeout
|
|
[ 95.890755] Call Trace:
|
|
[ 95.890755] <TASK>
|
|
[ 95.890755] dump_stack_lvl+0x45/0x110
|
|
[ 95.890755] print_address_description+0x78/0x390
|
|
[ 95.890755] print_report+0x11b/0x250
|
|
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_report+0x139/0x170
|
|
[ 95.890755] ? update_load_avg+0xe5/0x9f0
|
|
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] kasan_check_range+0x2c3/0x2e0
|
|
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
|
|
[ 95.890755] process_one_work+0x561/0xc50
|
|
[ 95.890755] worker_thread+0xab2/0x13c0
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] kthread+0x279/0x300
|
|
[ 95.890755] ? pr_cont_work+0x490/0x490
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork+0x34/0x60
|
|
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
|
|
[ 95.890755] ret_from_fork_asm+0x11/0x20
|
|
[ 95.890755] </TASK>
|
|
[ 95.890755]
|
|
[ 95.890755] Allocated by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] __kasan_kmalloc+0x86/0x90
|
|
[ 95.890755] __kmalloc+0x17f/0x360
|
|
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
|
|
[ 95.890755] sk_alloc+0x31/0x4e0
|
|
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
|
|
[ 95.890755] sco_sock_create+0xad/0x320
|
|
[ 95.890755] bt_sock_create+0x145/0x320
|
|
[ 95.890755] __sock_create+0x2e1/0x650
|
|
[ 95.890755] __sys_socket+0xd0/0x280
|
|
[ 95.890755] __x64_sys_socket+0x75/0x80
|
|
[ 95.890755] do_syscall_64+0xc4/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] Freed by task 506:
|
|
[ 95.890755] kasan_save_track+0x3f/0x70
|
|
[ 95.890755] kasan_save_free_info+0x40/0x50
|
|
[ 95.890755] poison_slab_object+0x118/0x180
|
|
[ 95.890755] __kasan_slab_free+0x12/0x30
|
|
[ 95.890755] kfree+0xb2/0x240
|
|
[ 95.890755] __sk_destruct+0x317/0x410
|
|
[ 95.890755] sco_sock_release+0x232/0x280
|
|
[ 95.890755] sock_close+0xb2/0x210
|
|
[ 95.890755] __fput+0x37f/0x770
|
|
[ 95.890755] task_work_run+0x1ae/0x210
|
|
[ 95.890755] get_signal+0xe17/0xf70
|
|
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
|
|
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
|
|
[ 95.890755] do_syscall_64+0xd1/0x1b0
|
|
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
|
|
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 95.890755] The buggy address is located 128 bytes inside of
|
|
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
|
|
[ 95.890755]
|
|
[ 95.890755] The buggy address belongs to the physical page:
|
|
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
|
|
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
|
|
[ 95.890755] ano
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-27398</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
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-SP3</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-1650</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:
|
|
|
|
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
|
|
|
|
Do the cache flush of converted pages in svm_register_enc_region() before
|
|
dropping kvm->lock to fix use-after-free issues where region and/or its
|
|
array of pages could be freed by a different task, e.g. if userspace has
|
|
__unregister_enc_region_locked() already queued up for the region.
|
|
|
|
Note, the "obvious" alternative of using local variables doesn't fully
|
|
resolve the bug, as region->pages is also dynamically allocated. I.e. the
|
|
region structure itself would be fine, but region->pages could be freed.
|
|
|
|
Flushing multiple pages under kvm->lock is unfortunate, but the entire
|
|
flow is a rare slow path, and the manual flush is only needed on CPUs that
|
|
lack coherency for encrypted memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-35791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
wifi: iwlwifi: dbg-tlv: ensure NUL termination
|
|
|
|
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
|
|
ensure the string is terminated correctly before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-35845</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-35849</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</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:
|
|
|
|
pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
|
|
|
|
devm_kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure. Ensure the allocation was successful
|
|
by checking the pointer validity.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-24</ReleaseDate>
|
|
<CVE>CVE-2024-35943</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-1650</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |