oesa-2025-2349
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix reading strings from synthetic events
The follow commands caused a crash:
# cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable
BOOM!
The problem is that the synthetic event field "char file[]" will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses.
Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in).
Now the above can show:
packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr
in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp
packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix check for probe enabled in kill_kprobe()
In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always false.
The disarm_kprobe_ftrace() call introduced by commit:
0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists.
Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag.(CVE-2022-50266)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix order >= MAX_ORDER warning due to crafted negative i_size
As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly.
Let's fall back to the generic path to deal with such unusual i_size.
[1] https://lore.kernel.org/r/(CVE-2022-50313)
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid deadlock in fs reclaim with page writeback
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like:
CPU0 CPU1
ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever
Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.(CVE-2023-53149)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293] Call Trace: <TASK> call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0
Fix the problem by adding cond_resched() to raid10 like what raid1 did.
Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)
In the Linux kernel, a memory leak vulnerability exists in the SCSI core component. When device_add() fails, the memory allocated by dev_set_name() for the device name is not properly freed. As per the device_add() comment documentation, put_device() should be used to decrease the reference count in the error path, but the current implementation fails to handle this correctly, resulting in a memory leak.(CVE-2023-53174)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memleak due to fentry attach failure
If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms.
This meamleak can be verified by a simple bpf program as follows:
SEC("fentry/trap_init") int fentry_run() { return 0; }
It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms.
$ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]
$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static
$ echo $((6442453466 & 0x7fffffff)) 2522
Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.(CVE-2023-53221)
In the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: check slab-out-of-bounds in md_bitmap_get_counter
If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage() will return -EINVAL because 'page >= bitmap->pages', but the return value was not checked immediately in md_bitmap_get_counter() in order to set *blocks value and slab-out-of-bounds occurs.
Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() and return directly if true.(CVE-2023-53357)
In the Linux kernel Bluetooth component, a potential use-after-free vulnerability exists when clearing keys. Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk"), the code cannot access k after kfree_rcu() call.(CVE-2023-53386)
In the Linux kernel, a slab-out-of-bounds vulnerability exists in the ntfs_listxattr() function of the NTFS filesystem. When ea->name_len is 0, the iteration logic error causes Add2Ptr() to access invalid memory, resulting in a kernel panic. This vulnerability can be exploited by attackers to cause system crashes.(CVE-2023-53420)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure
If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization.(CVE-2025-38695)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix soft lockup in br_multicast_query_expired()
When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue.
watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ>
This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up
The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.(CVE-2025-39773)
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix potential warning in trace_printk_seq during ftrace_dump
When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition.
The issue occurs because:
CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger
!trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL
trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)
In the context between trace_empty() and trace_find_next_entry_inc()
during ftrace_dump, the ring buffer data was consumed by other readers.
This caused trace_find_next_entry_inc to return NULL, failing to populate
iter.seq. At this point, due to the prior trace_iterator_reset, both
iter.seq.len and iter.seq.size were set to 0. Since they are equal,
the WARN_ON_ONCE condition is triggered.
Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.(CVE-2025-39813)
In the Linux kernel, the following vulnerability has been resolved:
trace/fgraph: Fix the warning caused by missing unregister notifier
This warning was triggered during testing on v6.16:
notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: <TASK> blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f
When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written.
Fixed by adding unregister_pm_notifier in the exception path.(CVE-2025-39829)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"perf-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-283.0.0.185.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-283.0.0.185.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"perf-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-283.0.0.185.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-283.0.0.185.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix reading strings from synthetic events\n\nThe follow commands caused a crash:\n\n # cd /sys/kernel/tracing\n # echo \u0026apos;s:open char file[]\u0026apos; \u0026gt; dynamic_events\n # echo \u0026apos;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)\u0026apos; \u0026gt; events/syscalls/sys_enter_openat/trigger\u0026apos;\n # echo 1 \u0026gt; events/synthetic/open/enable\n\nBOOM!\n\nThe problem is that the synthetic event field \u0026quot;char file[]\u0026quot; will read\nthe value given to it as a string without any memory checks to make sure\nthe address is valid. The above example will pass in the user space\naddress and the sythetic event code will happily call strlen() on it\nand then strscpy() where either one will cause an oops when accessing\nuser space addresses.\n\nUse the helper functions from trace_kprobe and trace_eprobe that can\nread strings safely (and actually succeed when the address is from user\nspace and the memory is mapped in).\n\nNow the above can show:\n\n packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr\n in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp\n packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Fix check for probe enabled in kill_kprobe()\n\nIn kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be\ncalled always fails. This is because before that we set the\nKPROBE_FLAG_GONE flag for kprobe so that \u0026quot;!kprobe_disabled(p)\u0026quot; is always\nfalse.\n\nThe disarm_kprobe_ftrace() call introduced by commit:\n\n 0cb2f1372baa (\u0026quot;kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler\u0026quot;)\n\nto fix the NULL pointer reference problem. When the probe is enabled, if\nwe do not disarm it, this problem still exists.\n\nFix it by putting the probe enabled check before setting the\nKPROBE_FLAG_GONE flag.(CVE-2022-50266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix order \u0026gt;= MAX_ORDER warning due to crafted negative i_size\n\nAs syzbot reported [1], the root cause is that i_size field is a\nsigned type, and negative i_size is also less than EROFS_BLKSIZ.\nAs a consequence, it\u0026apos;s handled as fast symlink unexpectedly.\n\nLet\u0026apos;s fall back to the generic path to deal with such unusual i_size.\n\n[1] https://lore.kernel.org/r/(CVE-2022-50313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid deadlock in fs reclaim with page writeback\n\nExt4 has a filesystem wide lock protecting ext4_writepages() calls to\navoid races with switching of journalled data flag or inode format. This\nlock can however cause a deadlock like:\n\nCPU0 CPU1\n\next4_writepages()\n percpu_down_read(sbi-\u0026gt;s_writepages_rwsem);\n ext4_change_inode_journal_flag()\n percpu_down_write(sbi-\u0026gt;s_writepages_rwsem);\n - blocks, all readers block from now on\n ext4_do_writepages()\n ext4_init_io_end()\n kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)\n fs_reclaim frees dentry...\n dentry_unlink_inode()\n iput() - last ref =\u0026gt;\n iput_final() - inode dirty =\u0026gt;\n write_inode_now()...\n ext4_writepages() tries to acquire sbi-\u0026gt;s_writepages_rwsem\n and blocks forever\n\nMake sure we cannot recurse into filesystem reclaim from writeback code\nto avoid the deadlock.(CVE-2023-53149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: prevent soft lockup while flush writes\n\nCurrently, there is no limit for raid1/raid10 plugged bio. While flushing\nwrites, raid1 has cond_resched() while raid10 doesn\u0026apos;t, and too many\nwrites can cause soft lockup.\n\nFollow up soft lockup can be triggered easily with writeback test for\nraid10 with ramdisks:\n\nwatchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n call_rcu+0x16/0x20\n put_object+0x41/0x80\n __delete_object+0x50/0x90\n delete_object_full+0x2b/0x40\n kmemleak_free+0x46/0xa0\n slab_free_freelist_hook.constprop.0+0xed/0x1a0\n kmem_cache_free+0xfd/0x300\n mempool_free_slab+0x1f/0x30\n mempool_free+0x3a/0x100\n bio_free+0x59/0x80\n bio_put+0xcf/0x2c0\n free_r10bio+0xbf/0xf0\n raid_end_bio_io+0x78/0xb0\n one_write_done+0x8a/0xa0\n raid10_end_write_request+0x1b4/0x430\n bio_endio+0x175/0x320\n brd_submit_bio+0x3b9/0x9b7 [brd]\n __submit_bio+0x69/0xe0\n submit_bio_noacct_nocheck+0x1e6/0x5a0\n submit_bio_noacct+0x38c/0x7e0\n flush_pending_writes+0xf0/0x240\n raid10d+0xac/0x1ed0\n\nFix the problem by adding cond_resched() to raid10 like what raid1 did.\n\nNote that unlimited plugged bio still need to be optimized, for example,\nin the case of lots of dirty pages writeback, this will take lots of\nmemory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)\n\nIn the Linux kernel, a memory leak vulnerability exists in the SCSI core component. When device_add() fails, the memory allocated by dev_set_name() for the device name is not properly freed. As per the device_add() comment documentation, put_device() should be used to decrease the reference count in the error path, but the current implementation fails to handle this correctly, resulting in a memory leak.(CVE-2023-53174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memleak due to fentry attach failure\n\nIf it fails to attach fentry, the allocated bpf trampoline image will be\nleft in the system. That can be verified by checking /proc/kallsyms.\n\nThis meamleak can be verified by a simple bpf program as follows:\n\n SEC(\u0026quot;fentry/trap_init\u0026quot;)\n int fentry_run()\n {\n return 0;\n }\n\nIt will fail to attach trap_init because this function is freed after\nkernel init, and then we can find the trampoline image is left in the\nsystem by checking /proc/kallsyms.\n\n $ tail /proc/kallsyms\n ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf]\n ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf]\n\n $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep \u0026quot;FUNC \u0026apos;trap_init\u0026apos;\u0026quot;\n [2522] FUNC \u0026apos;trap_init\u0026apos; type_id=119 linkage=static\n\n $ echo $((6442453466 \u0026amp; 0x7fffffff))\n 2522\n\nNote that there are two left bpf trampoline images, that is because the\nlibbpf will fallback to raw tracepoint if -EINVAL is returned.(CVE-2023-53221)\n\nIn the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its \u0026apos;data\u0026apos; parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: check slab-out-of-bounds in md_bitmap_get_counter\n\nIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()\nwill return -EINVAL because \u0026apos;page \u0026gt;= bitmap-\u0026gt;pages\u0026apos;, but the return value\nwas not checked immediately in md_bitmap_get_counter() in order to set\n*blocks value and slab-out-of-bounds occurs.\n\nMove check of \u0026apos;page \u0026gt;= bitmap-\u0026gt;pages\u0026apos; to md_bitmap_get_counter() and\nreturn directly if true.(CVE-2023-53357)\n\nIn the Linux kernel Bluetooth component, a potential use-after-free vulnerability exists when clearing keys. Similar to commit c5d2b6fa26b5 (\u0026quot;Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk\u0026quot;), the code cannot access k after kfree_rcu() call.(CVE-2023-53386)\n\nIn the Linux kernel, a slab-out-of-bounds vulnerability exists in the ntfs_listxattr() function of the NTFS filesystem. When ea-\u0026gt;name_len is 0, the iteration logic error causes Add2Ptr() to access invalid memory, resulting in a kernel panic. This vulnerability can be exploited by attackers to cause system crashes.(CVE-2023-53420)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure\n\nIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the\nresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may\noccur before sli4_hba.hdwqs are allocated. This may result in a null\npointer dereference when attempting to take the abts_io_buf_list_lock for\nthe first hardware queue. Fix by adding a null ptr check on\nphba-\u0026gt;sli4_hba.hdwq and early return because this situation means there\nmust have been an error during port initialization.(CVE-2025-38695)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n\u0026apos;time\u0026apos; in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n __netdev_alloc_skb+0x2e/0x3a0\n br_ip6_multicast_alloc_query+0x212/0x1b70\n __br_multicast_send_query+0x376/0xac0\n br_multicast_send_query+0x299/0x510\n br_multicast_query_expired.constprop.0+0x16d/0x1b0\n call_timer_fn+0x3b/0x2a0\n __run_timers+0x619/0x950\n run_timer_softirq+0x11c/0x220\n handle_softirqs+0x18e/0x560\n __irq_exit_rcu+0x158/0x1a0\n sysvec_apic_timer_interrupt+0x76/0x90\n \u0026lt;/IRQ\u0026gt;\n\nThis issue can be reproduced with:\n ip link add br0 type bridge\n echo 1 \u0026gt; /sys/class/net/br0/bridge/multicast_querier\n echo 0xffffffffffffffff \u0026gt;\n \t/sys/class/net/br0/bridge/multicast_query_interval\n ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a (\u0026quot;net: bridge: mcast: add and enforce query\ninterval minimum\u0026quot;), add check for the query interval maximum to fix this\nissue.(CVE-2025-39773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix potential warning in trace_printk_seq during ftrace_dump\n\nWhen calling ftrace_dump_one() concurrently with reading trace_pipe,\na WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race\ncondition.\n\nThe issue occurs because:\n\nCPU0 (ftrace_dump) CPU1 (reader)\necho z \u0026gt; /proc/sysrq-trigger\n\n!trace_empty(\u0026amp;iter)\ntrace_iterator_reset(\u0026amp;iter) \u0026lt;- len = size = 0\n cat /sys/kernel/tracing/trace_pipe\ntrace_find_next_entry_inc(\u0026amp;iter)\n __find_next_entry\n ring_buffer_empty_cpu \u0026lt;- all empty\n return NULL\n\ntrace_printk_seq(\u0026amp;iter.seq)\n WARN_ON_ONCE(s-\u0026gt;seq.len \u0026gt;= s-\u0026gt;seq.size)\n\nIn the context between trace_empty() and trace_find_next_entry_inc()\nduring ftrace_dump, the ring buffer data was consumed by other readers.\nThis caused trace_find_next_entry_inc to return NULL, failing to populate\n`iter.seq`. At this point, due to the prior trace_iterator_reset, both\n`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,\nthe WARN_ON_ONCE condition is triggered.\n\nMove the trace_printk_seq() into the if block that checks to make sure the\nreturn value of trace_find_next_entry_inc() is non-NULL in\nftrace_dump_one(), ensuring the \u0026apos;iter.seq\u0026apos; is properly populated before\nsubsequent operations.(CVE-2025-39813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntrace/fgraph: Fix the warning caused by missing unregister notifier\n\nThis warning was triggered during testing on v6.16:\n\nnotifier callback ftrace_suspend_notifier_call already registered\nWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n blocking_notifier_chain_register+0x34/0x60\n register_ftrace_graph+0x330/0x410\n ftrace_profile_write+0x1e9/0x340\n vfs_write+0xf8/0x420\n ? filp_flush+0x8a/0xa0\n ? filp_close+0x1f/0x30\n ? do_dup2+0xaf/0x160\n ksys_write+0x65/0xe0\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen writing to the function_profile_enabled interface, the notifier was\nnot unregistered after start_graph_tracing failed, causing a warning the\nnext time function_profile_enabled was written.\n\nFixed by adding unregister_pm_notifier in the exception path.(CVE-2025-39829)",
"id": "OESA-2025-2349",
"modified": "2026-08-06T11:09:25Z",
"published": "2025-09-26T11:09:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50255"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50266"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53221"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53332"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53386"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53420"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39813"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39829"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50255",
"CVE-2022-50266",
"CVE-2022-50313",
"CVE-2023-53149",
"CVE-2023-53151",
"CVE-2023-53174",
"CVE-2023-53221",
"CVE-2023-53332",
"CVE-2023-53357",
"CVE-2023-53386",
"CVE-2023-53420",
"CVE-2025-38695",
"CVE-2025-39773",
"CVE-2025-39813",
"CVE-2025-39829"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.