OESA-2026-1339 (CVE-2024-35808)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.(CVE-2024-50102)
In the Linux kernel, the following vulnerability has been resolved:
genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated.
2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.
This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.
However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs.
Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.
The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.(CVE-2025-38062)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.(CVE-2025-38303)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: fix data race in show_numa_info()
The following data-race was found in show_numa_info():
================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show
read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
value changed: 0x0000008f -> 0x00000000
According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.
v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)
In the Linux kernel, the following vulnerability has been resolved:
s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again
Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear.
Restore the fix and add a comment.(CVE-2025-38489)
In the Linux kernel, the following vulnerability has been resolved:
iio: common: st_sensors: Fix use of uninitialize device structs
Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device.
This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well.
The issue is reported and traced here: 1
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject duplicate device on updates
A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device.
Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case.
WARNING is hit when unregistering the hook:
[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible.
As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().(CVE-2025-38685)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.
Since the driver uses a shared workqueue (qat_misc_wq) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
pm_bh_handler+0x1d2/0x250 [intel_qat]
process_one_work+0x171/0x340
worker_thread+0x277/0x3a0
kthread+0xf0/0x120
ret_from_fork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.
Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL pointer dereference in UTF16 conversion
There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...(CVE-2025-39843)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()
kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and always allocate memory using the hardcoded GFP_KERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFP_NOFS and GFP_NOIO allocations.
Page table allocations performed during shadow population also ignore the external gfp_mask. To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope.
xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.
There was a report here https://lkml.kernel.org/r/(CVE-2025-39910)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
-
Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function.
-
Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it.
-
Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
x86/vmscape: Add conditional IBPB mitigation
VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.
Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.
This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.
The intent is to integrate and optimize these cases post-embargo.
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-139.0.0.133.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-139.0.0.133.oe2403sp2"
}
],
"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\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\n\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: fix user address masking non-canonical speculation issue\n\nIt turns out that AMD has a \u0026quot;Meltdown Lite(tm)\u0026quot; issue with non-canonical\naccesses in kernel space. And so using just the high bit to decide\nwhether an access is in user space or kernel space ends up with the good\nold \u0026quot;leak speculative data\u0026quot; if you have the right gadget using the\nresult:\n\n CVE-2020-12965 \u201cTransient Execution of Non-Canonical Accesses\u201c\n\nNow, the kernel surrounds the access with a STAC/CLAC pair, and those\ninstructions end up serializing execution on older Zen architectures,\nwhich closes the speculation window.\n\nBut that was true only up until Zen 5, which renames the AC bit [1].\nThat improves performance of STAC/CLAC a lot, but also means that the\nspeculation window is now open.\n\nNote that this affects not just the new address masking, but also the\nregular valid_user_address() check used by access_ok(), and the asm\nversion of the sign bit check in the get_user() helpers.\n\nIt does not affect put_user() or clear_user() variants, since there\u0026apos;s no\nspeculative result to be used in a gadget for those operations.(CVE-2024-50102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie\n\nThe IOMMU translation for MSI message addresses has been a 2-step process,\nseparated in time:\n\n 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address\n is stored in the MSI descriptor when an MSI interrupt is allocated.\n\n 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a\n translated message address.\n\nThis has an inherent lifetime problem for the pointer stored in the cookie\nthat must remain valid between the two steps. However, there is no locking\nat the irq layer that helps protect the lifetime. Today, this works under\nthe assumption that the iommu domain is not changed while MSI interrupts\nbeing programmed. This is true for normal DMA API users within the kernel,\nas the iommu domain is attached before the driver is probed and cannot be\nchanged while a driver is attached.\n\nClassic VFIO type1 also prevented changing the iommu domain while VFIO was\nrunning as it does not support changing the \u0026quot;container\u0026quot; after starting up.\n\nHowever, iommufd has improved this so that the iommu domain can be changed\nduring VFIO operation. This potentially allows userspace to directly race\nVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and\nVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).\n\nThis potentially causes both the cookie pointer and the unlocked call to\niommu_get_domain_for_dev() on the MSI translation path to become UAFs.\n\nFix the MSI cookie UAF by removing the cookie pointer. The translated IOVA\naddress is already known during iommu_dma_prepare_msi() and cannot change.\nThus, it can simply be stored as an integer in the MSI descriptor.\n\nThe other UAF related to iommu_get_domain_for_dev() will be addressed in\npatch \u0026quot;iommu: Make iommu_dma_prepare_msi() into a generic operation\u0026quot; by\nusing the IOMMU group mutex.(CVE-2025-38062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix possible crashes on eir_create_adv_data\n\neir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER\nwithout checking if that would fit.(CVE-2025-38303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix data race in show_numa_info()\n\nThe following data-race was found in show_numa_info():\n\n==================================================================\nBUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show\n\nread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:\n show_numa_info mm/vmalloc.c:4936 [inline]\n vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nwrite to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:\n show_numa_info mm/vmalloc.c:4934 [inline]\n vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nvalue changed: 0x0000008f -\u0026gt; 0x00000000\n==================================================================\n\nAccording to this report,there is a read/write data-race because\nm-\u0026gt;private is accessible to multiple CPUs. To fix this, instead of\nallocating the heap in proc_vmalloc_init() and passing the heap address to\nm-\u0026gt;private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u0026lt;TASK\u0026gt;\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0026apos;s GEM buffer objects prevents\nthis from happening. The framebuffer\u0026apos;s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\u0026quot;drm/gem-shmem: Use dma_buf from GEM object\ninstance\u0026quot;) triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again\n\nCommit 7ded842b356d (\u0026quot;s390/bpf: Fix bpf_plt pointer arithmetic\u0026quot;) has\naccidentally removed the critical piece of commit c730fce7c70c\n(\u0026quot;s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\u0026quot;), causing\nintermittent kernel panics in e.g. perf\u0026apos;s on_switch() prog to reappear.\n\nRestore the fix and add a comment.(CVE-2025-38489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: common: st_sensors: Fix use of uninitialize device structs\n\nThroughout the various probe functions \u0026amp;indio_dev-\u0026gt;dev is used before it\nis initialized. This caused a kernel panic in st_sensors_power_enable()\nwhen the call to devm_regulator_bulk_get_enable() fails and then calls\ndev_err_probe() with the uninitialized device.\n\nThis seems to only cause a panic with dev_err_probe(), dev_err(),\ndev_warn() and dev_info() don\u0026apos;t seem to cause a panic, but are fixed\nas well.\n\nThe issue is reported and traced here: [1](CVE-2025-38531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject duplicate device on updates\n\nA chain/flowtable update with duplicated devices in the same batch is\npossible. Unfortunately, netdev event path only removes the first\ndevice that is found, leaving unregistered the hook of the duplicated\ndevice.\n\nCheck if a duplicated device exists in the transaction batch, bail out\nwith EEXIST in such case.\n\nWARNING is hit when unregistering the hook:\n\n [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150\n [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full)\n [...]\n [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix vmalloc out-of-bounds write in fast_imageblit\n\nThis issue triggers when a userspace program does an ioctl\nFBIOPUT_CON2FBMAP by passing console number and frame buffer number.\nIdeally this maps console to frame buffer and updates the screen if\nconsole is visible.\n\nAs part of mapping it has to do resize of console according to frame\nbuffer info. if this resize fails and returns from vc_do_resize() and\ncontinues further. At this point console and new frame buffer are mapped\nand sets display vars. Despite failure still it continue to proceed\nupdating the screen at later stages where vc_data is related to previous\nframe buffer and frame buffer info and display vars are mapped to new\nframe buffer and eventully leading to out-of-bounds write in\nfast_imageblit(). This bheviour is excepted only when fg_console is\nequal to requested console which is a visible console and updates screen\nwith invalid struct references in fbcon_putcs().(CVE-2025-38685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n BUG: unable to handle page fault for address: ffa000002e50a01c\n #PF: supervisor read access in kernel mode\n RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n Call Trace:\n pm_bh_handler+0x1d2/0x250 [intel_qat]\n process_one_work+0x171/0x340\n worker_thread+0x277/0x3a0\n kthread+0xf0/0x120\n ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.(CVE-2025-39721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where \u0026apos;*from\u0026apos; is dereferenced, causing a crash.\n\nThis patch adds a check for NULL \u0026apos;src\u0026apos; in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...(CVE-2025-39843)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()\n\nkasan_populate_vmalloc() and its helpers ignore the caller\u0026apos;s gfp_mask and\nalways allocate memory using the hardcoded GFP_KERNEL flag. This makes\nthem inconsistent with vmalloc(), which was recently extended to support\nGFP_NOFS and GFP_NOIO allocations.\n\nPage table allocations performed during shadow population also ignore the\nexternal gfp_mask. To preserve the intended semantics of GFP_NOFS and\nGFP_NOIO, wrap the apply_to_page_range() calls into the appropriate\nmemalloc scope.\n\nxfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.\n\nThere was a report here\nhttps://lkml.kernel.org/r/(CVE-2025-39910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix null-deref in agg_dequeue\n\nTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)\nwhen cl-\u0026gt;qdisc-\u0026gt;ops-\u0026gt;peek(cl-\u0026gt;qdisc) returns NULL, we check the return\nvalue before using it, similar to the existing approach in sch_hfsc.c.\n\nTo avoid code duplication, the following changes are made:\n\n1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static\ninline function.\n\n2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to\ninclude/net/pkt_sched.h so that sch_qfq can reuse it.\n\n3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmscape: Add conditional IBPB mitigation\n\nVMSCAPE is a vulnerability that exploits insufficient branch predictor\nisolation between a guest and a userspace hypervisor (like QEMU). Existing\nmitigations already protect kernel/KVM from a malicious guest. Userspace\ncan additionally be protected by flushing the branch predictors after a\nVMexit.\n\nSince it is the userspace that consumes the poisoned branch predictors,\nconditionally issue an IBPB after a VMexit and before returning to\nuserspace. Workloads that frequently switch between hypervisor and\nuserspace will incur the most overhead from the new IBPB.\n\nThis new IBPB is not integrated with the existing IBPB sites. For\ninstance, a task can use the existing speculation control prctl() to\nget an IBPB at context switch time. With this implementation, the\nIBPB is doubled up: one at context switch and another before running\nuserspace.\n\nThe intent is to integrate and optimize these cases post-embargo.\n\n[ dhansen: elaborate on suboptimal IBPB solution ](CVE-2025-40300)",
"id": "OESA-2026-1339",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39721"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40300"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-35808",
"CVE-2024-50102",
"CVE-2025-38062",
"CVE-2025-38303",
"CVE-2025-38383",
"CVE-2025-38449",
"CVE-2025-38489",
"CVE-2025-38531",
"CVE-2025-38676",
"CVE-2025-38678",
"CVE-2025-38685",
"CVE-2025-39721",
"CVE-2025-39744",
"CVE-2025-39749",
"CVE-2025-39838",
"CVE-2025-39843",
"CVE-2025-39910",
"CVE-2025-39913",
"CVE-2025-40083",
"CVE-2025-40105",
"CVE-2025-40300"
]
}
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.