OESA-2026-2754 (CVE-2025-38702)
Vulnerability from osv_openeuler – Published: 2026-06-24 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fix potential buffer overflow in do_register_framebuffer()
The current implementation may lead to buffer overflow when: 1. Unregistration creates NULL gaps in registered_fb[] 2. All array slots become occupied despite num_registered_fb < FB_MAX 3. The registration loop exceeds array bounds
Add boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)
In the Linux kernel, the following vulnerability has been resolved:
hfs: validate record offset in hfsplus_bmap_alloc
hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size
[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] <TASK> [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 <f3> 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] </TASK>
When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff
len = hfs_brec_lenoff(node, 2, &off16);
off = off16;
off += node->page_offset;
pagep = node->page + (off >> PAGE_SHIFT);
data = kmap_local_page(*pagep);
However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node.
This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.(CVE-2025-40349)
In the Linux kernel, the following vulnerability has been resolved:
can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak
Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").
In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted).
However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close().
Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.(CVE-2026-23058)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer
smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *.
When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object:
1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]
KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer:
BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: <TASK> smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception
Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately.
The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.(CVE-2026-31507)
In the Linux kernel, the following vulnerability has been resolved:
bcache: fix cached_dev.sb_bio use-after-free and crash
In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:
[6888366.280350] Call Trace:
[6888366.280452] blk_update_request+0x14e/0x370
[6888366.280561] blk_mq_end_request+0x1a/0x130
[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]
[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]
[6888366.280903] __complete_request+0x22/0x70 [libceph]
[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]
[6888366.281164] ? inet_recvmsg+0x5b/0xd0
[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]
[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]
[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]
[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]
After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped.
Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.
This patch hopes to wait for sb_write to complete in cached_dev_free.
It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.(CVE-2026-31580)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: fix nfeeds state corruption on start_streaming failure
syzbot reported a memory leak in vidtv_psi_service_desc_init [1].
When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream.
This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early.
Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds.
[1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm "syz.0.17", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239(CVE-2026-31585)
In the Linux kernel, the following vulnerability has been resolved:
mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()
cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free:
BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385)
Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)
** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410")
I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh
(The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.)
Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.(CVE-2026-31586)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: handle invalid dinode in ocfs2_group_extend
[BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ...
[CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl.
[FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.(CVE-2026-31596)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY
filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c:
"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."
When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free.
Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.(CVE-2026-31597)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible deadlock between unlink and dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.(CVE-2026-31598)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections
syzbot reported a general protection fault in vidtv_psi_desc_assign [1].
vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault.
Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return.
[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: <TASK> vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239(CVE-2026-31599)
In the Linux kernel, the following vulnerability has been resolved:
staging: sm750fb: fix division by zero in ps_to_hz()
ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero.
Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.(CVE-2026-31603)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()
Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data.
Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized:
drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes)
Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.(CVE-2026-31626)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat
A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request.
The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow:
<4> [487.221889] Workqueue: i915-unordered engine_retire [i915]
<4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0
...
<4> [487.222707] Call Trace:
<4> [487.222711] <TASK>
<4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]
<4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]
<4> [487.223566] __engine_park+0xb9/0x650 [i915]
<4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]
<4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]
<4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]
<4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]
<4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]
<4> [487.226178] i915_request_retire+0x1c/0x40 [i915]
<4> [487.226625] engine_retire+0x122/0x180 [i915]
<4> [487.227037] process_one_work+0x239/0x760
<4> [487.227060] worker_thread+0x200/0x3f0
<4> [487.227068] ? __pfx_worker_thread+0x10/0x10
<4> [487.227075] kthread+0x10d/0x150
<4> [487.227083] ? __pfx_kthread+0x10/0x10
<4> [487.227092] ret_from_fork+0x3d4/0x480
<4> [487.227099] ? __pfx_kthread+0x10/0x10
<4> [487.227107] ret_from_fork_asm+0x1a/0x30
<4> [487.227141] </TASK>
Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it.
(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)(CVE-2026-31656)
In the Linux kernel, the following vulnerability has been resolved:
fuse: reject oversized dirents in page cache
fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE.
As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page.
Reject dirents that cannot fit in a single page before copying them into the readdir cache.(CVE-2026-31694)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_helper: pass helper to expect cleanup
nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup.
After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free.
Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed.
BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)(CVE-2026-43027)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: ensure names are nul-terminated
Reject names that lack a \0 character before feeding them to functions that expect c-strings.
Fixes tag is the most recent commit that needs this change.(CVE-2026-43028)
In the Linux kernel, the following vulnerability has been resolved:
dcache: Limit the minimal number of bucket to two
There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260
There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!
Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.(CVE-2026-43071)
In the Linux kernel, the following vulnerability has been resolved:
dm-verity: correctly handle dm_bufio_client_create() failure
If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.(CVE-2026-43132)
In the Linux kernel, the following vulnerability has been resolved:
xfs: delete attr leaf freemap entries when empty
Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block.
This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size.
However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later.
For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap.
It looks like this bug has been in the codebase for quite a long time.(CVE-2026-43187)
In the Linux kernel, the following vulnerability has been resolved:
media: mtk-mdp: Fix error handling in probe function
Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak.
Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.(CVE-2026-43207)
In the Linux kernel, the following vulnerability has been resolved:
ntfs: ->d_compare() must not block
... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now.
Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX.(CVE-2026-43245)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid double-rtnl_lock ELP metric worker
batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock.
To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held.
But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.(CVE-2026-43382)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()
In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime.
A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer.
Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released.(CVE-2026-43437)
In the Linux kernel, the following vulnerability has been resolved:
bonding: alb: fix UAF in rlb_arp_recv during bond up/down
The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN.
However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag.
[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfxnetifreceive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfxnetifreceive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ>
The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry.
Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().(CVE-2026-45970)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid early lgr access in smc_clc_wait_msg
A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group.
The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged.
This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.(CVE-2026-46027)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence:
ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1]
rt_genid_bump_ipv6()
-> bumps fib6_sernum
[fib6_sernum from W to Z]
ip6_route_output()
-> ip6_pol_route()
-> FIB lookup resolves fib6_nh
[nhid=N]
-> rt6_get_pcpu_route()
pcpu_rt->sernum != fib6_sernum
[W <> Z, stale]
-> prev = xchg(rt6i_pcpu, NULL)
-> dst_release(prev)
[prev is pcpu_rt,
refcount 1->0, dead]
dst = skb_dst(skb)
[dst is the dead pcpu_rt]
dst_cache_set_ip6(dst)
-> dst_hold() on dead dst
-> WARN / use-after-free
For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry.
Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.(CVE-2026-46099)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory.
Grab the same locks the other two callers use.(CVE-2026-46112)
In the Linux kernel, improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.(CVE-2026-46174)
In the Linux kernel's RDMA/vmw_pvrdma driver, the error path of pvrdma_alloc_ucontext() calls pvrdma_uar_free(), but pvrdma_dealloc_ucontext() already calls pvrdma_uar_free() internally, causing a double free during error handling, which may lead to kernel crash or memory corruption.(CVE-2026-46189)
In the Linux kernel, when Extended Sequence Number (ESN) is enabled, the AH (Authentication Header) module incorrectly reconstructs the temporary auth/ICV layout in async hash callbacks, omitting the 4-byte seqhi slot for ESN high bits. This causes wrong byte copying/comparison on both IPv4 and IPv6 paths when using an async AH implementation, leading to 100% packet loss. For example, in UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails. After the fix, offsets are corrected and ping succeeds.(CVE-2026-46193)
In the Linux kernel, the following vulnerability has been resolved:
dm: fix a buffer overflow in ioctl processing
Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status:
- The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there
- Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr);
- The alignment doesn't check overflow, so outptr could point past the buffer end
- The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf);
- If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number
- With "remaining" being high, the code writes more data past the end of the buffer
Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally(CVE-2026-46294)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix pedit partial COW leading to page cache corruption
tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd.
Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.(CVE-2026-46331)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"perf-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-320.0.0.222.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-320.0.0.222.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"perf-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-320.0.0.222.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-320.0.0.222.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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\nfbdev: fix potential buffer overflow in do_register_framebuffer()\n\nThe current implementation may lead to buffer overflow when:\n1. Unregistration creates NULL gaps in registered_fb[]\n2. All array slots become occupied despite num_registered_fb \u0026lt; FB_MAX\n3. The registration loop exceeds array bounds\n\nAdd boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfs: validate record offset in hfsplus_bmap_alloc\n\nhfsplus_bmap_alloc can trigger a crash if a\nrecord offset or length is larger than node_size\n\n[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0\n[ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183\n[ 15.265949]\n[ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)\n[ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 15.266167] Call Trace:\n[ 15.266168] \u0026lt;TASK\u0026gt;\n[ 15.266169] dump_stack_lvl+0x53/0x70\n[ 15.266173] print_report+0xd0/0x660\n[ 15.266181] kasan_report+0xce/0x100\n[ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0\n[ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0\n[ 15.266217] hfsplus_brec_insert+0x870/0xb00\n[ 15.266222] __hfsplus_ext_write_extent+0x428/0x570\n[ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910\n[ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200\n[ 15.266233] hfsplus_file_extend+0x5a7/0x1000\n[ 15.266237] hfsplus_get_block+0x12b/0x8c0\n[ 15.266238] __block_write_begin_int+0x36b/0x12c0\n[ 15.266251] block_write_begin+0x77/0x110\n[ 15.266252] cont_write_begin+0x428/0x720\n[ 15.266259] hfsplus_write_begin+0x51/0x100\n[ 15.266262] cont_write_begin+0x272/0x720\n[ 15.266270] hfsplus_write_begin+0x51/0x100\n[ 15.266274] generic_perform_write+0x321/0x750\n[ 15.266285] generic_file_write_iter+0xc3/0x310\n[ 15.266289] __kernel_write_iter+0x2fd/0x800\n[ 15.266296] dump_user_range+0x2ea/0x910\n[ 15.266301] elf_core_dump+0x2a94/0x2ed0\n[ 15.266320] vfs_coredump+0x1d85/0x45e0\n[ 15.266349] get_signal+0x12e3/0x1990\n[ 15.266357] arch_do_signal_or_restart+0x89/0x580\n[ 15.266362] irqentry_exit_to_user_mode+0xab/0x110\n[ 15.266364] asm_exc_page_fault+0x26/0x30\n[ 15.266366] RIP: 0033:0x41bd35\n[ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 \u0026lt;f3\u0026gt; 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f\n[ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283\n[ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000\n[ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100\n[ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000\n[ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000\n[ 15.266376] \u0026lt;/TASK\u0026gt;\n\nWhen calling hfsplus_bmap_alloc to allocate a free node, this function\nfirst retrieves the bitmap from header node and map node using node-\u0026gt;page\ntogether with the offset and length from hfs_brec_lenoff\n\n```\nlen = hfs_brec_lenoff(node, 2, \u0026amp;off16);\noff = off16;\n\noff += node-\u0026gt;page_offset;\npagep = node-\u0026gt;page + (off \u0026gt;\u0026gt; PAGE_SHIFT);\ndata = kmap_local_page(*pagep);\n```\n\nHowever, if the retrieved offset or length is invalid(i.e. exceeds\nnode_size), the code may end up accessing pages outside the allocated\nrange for this node.\n\nThis patch adds proper validation of both offset and length before use,\npreventing out-of-bounds page access. Move is_bnode_offset_valid and\ncheck_and_correct_requested_length to hfsplus_fs.h, as they may be\nrequired by other functions.(CVE-2025-40349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak\n\nFix similar memory leak as in commit 7352e1d5932a (\u0026quot;can: gs_usb:\ngs_usb_receive_bulk_callback(): fix URB memory leak\u0026quot;).\n\nIn ems_usb_open(), the URBs for USB-in transfers are allocated, added to\nthe dev-\u0026gt;rx_submitted anchor and submitted. In the complete callback\nems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In\nems_usb_close() the URBs are freed by calling\nusb_kill_anchored_urbs(\u0026amp;dev-\u0026gt;rx_submitted).\n\nHowever, this does not take into account that the USB framework unanchors\nthe URB before the complete function is called. This means that once an\nin-URB has been completed, it is no longer anchored and is ultimately not\nreleased in ems_usb_close().\n\nFix the memory leak by anchoring the URB in the\nems_usb_read_bulk_callback() to the dev-\u0026gt;rx_submitted anchor.(CVE-2026-23058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer\n\nsmc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores\nthe pointer in pipe_buffer.private. The pipe_buf_operations for these\nbuffers used .get = generic_pipe_buf_get, which only increments the page\nreference count when tee(2) duplicates a pipe buffer. The smc_spd_priv\npointer itself was not handled, so after tee() both the original and the\ncloned pipe_buffer share the same smc_spd_priv *.\n\nWhen both pipes are subsequently released, smc_rx_pipe_buf_release() is\ncalled twice against the same object:\n\n 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct]\n 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]\n\nKASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which\nthen escalates to a NULL-pointer dereference and kernel panic via\nsmc_rx_update_consumer() when it chases the freed priv-\u0026gt;smc pointer:\n\n BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0\n Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_report+0xce/0x650\n kasan_report+0xc6/0x100\n smc_rx_pipe_buf_release+0x78/0x2a0\n free_pipe_info+0xd4/0x130\n pipe_release+0x142/0x160\n __fput+0x1c6/0x490\n __x64_sys_close+0x4f/0x90\n do_syscall_64+0xa6/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\n BUG: kernel NULL pointer dereference, address: 0000000000000020\n RIP: 0010:smc_rx_update_consumer+0x8d/0x350\n Call Trace:\n \u0026lt;TASK\u0026gt;\n smc_rx_pipe_buf_release+0x121/0x2a0\n free_pipe_info+0xd4/0x130\n pipe_release+0x142/0x160\n __fput+0x1c6/0x490\n __x64_sys_close+0x4f/0x90\n do_syscall_64+0xa6/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n Kernel panic - not syncing: Fatal exception\n\nBeyond the memory-safety problem, duplicating an SMC splice buffer is\nsemantically questionable: smc_rx_update_cons() would advance the\nconsumer cursor twice for the same data, corrupting receive-window\naccounting. A refcount on smc_spd_priv could fix the double-free, but\nthe cursor-accounting issue would still need to be addressed separately.\n\nThe .get callback is invoked by both tee(2) and splice_pipe_to_pipe()\nfor partial transfers; both will now return -EFAULT. Users who need\nto duplicate SMC socket data must use a copy-based read path.(CVE-2026-31507)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452] blk_update_request+0x14e/0x370\n[6888366.280561] blk_mq_end_request+0x1a/0x130\n[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903] __complete_request+0x22/0x70 [libceph]\n[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164] ? inet_recvmsg+0x5b/0xd0\n[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime. If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: fix nfeeds state corruption on start_streaming failure\n\nsyzbot reported a memory leak in vidtv_psi_service_desc_init [1].\n\nWhen vidtv_start_streaming() fails inside vidtv_start_feed(), the\nnfeeds counter is left incremented even though no feed was actually\nstarted. This corrupts the driver state: subsequent start_feed calls\nsee nfeeds \u0026gt; 1 and skip starting the mux, while stop_feed calls\neventually try to stop a non-existent stream.\n\nThis state corruption can also lead to memory leaks, since the mux\nand channel resources may be partially allocated during a failed\nstart_streaming but never cleaned up, as the stop path finds\ndvb-\u0026gt;streaming == false and returns early.\n\nFix by decrementing nfeeds back when start_streaming fails, keeping\nthe counter in sync with the actual number of active feeds.\n\n[1]\nBUG: memory leak\nunreferenced object 0xffff888145b50820 (size 32):\n comm \u0026quot;syz.0.17\u0026quot;, pid 6068, jiffies 4294944486\n backtrace (crc 90a0c7d4):\n vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288\n vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83\n vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524\n vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518\n vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]\n vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239(CVE-2026-31585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: blk-cgroup: fix use-after-free in cgwb_release_workfn()\n\ncgwb_release_workfn() calls css_put(wb-\u0026gt;blkcg_css) and then later accesses\nwb-\u0026gt;blkcg_css again via blkcg_unpin_online(). If css_put() drops the last\nreference, the blkcg can be freed asynchronously (css_free_rwork_fn -\u0026gt;\nblkcg_css_free -\u0026gt; kfree) before blkcg_unpin_online() dereferences the\npointer to access blkcg-\u0026gt;online_pin, resulting in a use-after-free:\n\n BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)\n Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531\n Workqueue: cgwb_release cgwb_release_workfn\n Call Trace:\n \u0026lt;TASK\u0026gt;\n blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)\n cgwb_release_workfn (mm/backing-dev.c:629)\n process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385)\n\n Freed by task 1016:\n kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561)\n css_free_rwork_fn (kernel/cgroup/cgroup.c:5542)\n process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)\n\n** Stack based on commit 66672af7a095 (\u0026quot;Add linux-next specific files\nfor 20260410\u0026quot;)\n\nI am seeing this crash sporadically in Meta fleet across multiple kernel\nversions. A full reproducer is available at:\nhttps://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh\n\n(The race window is narrow. To make it easily reproducible, inject a\nmsleep(100) between css_put() and blkcg_unpin_online() in\ncgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the\nreproducer triggers the splat reliably in less than a second.)\n\nFix this by moving blkcg_unpin_online() before css_put(), so the\ncgwb\u0026apos;s CSS reference keeps the blkcg alive while blkcg_unpin_online()\naccesses it.(CVE-2026-31586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: handle invalid dinode in ocfs2_group_extend\n\n[BUG]\nkernel BUG at fs/ocfs2/resize.c:308!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nRIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308\nCode: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe\nCall Trace:\n ...\n ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583\n x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ...\n\n[CAUSE]\nocfs2_group_extend() assumes that the global bitmap inode block\nreturned from ocfs2_inode_lock() has already been validated and\nBUG_ONs when the signature is not a dinode. That assumption is too\nstrong for crafted filesystems because the JBD2-managed buffer path\ncan bypass structural validation and return an invalid dinode to the\nresize ioctl.\n\n[FIX]\nValidate the dinode explicitly in ocfs2_group_extend(). If the global\nbitmap buffer does not contain a valid dinode, report filesystem\ncorruption with ocfs2_error() and fail the resize operation instead of\ncrashing the kernel.(CVE-2026-31596)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY\n\nfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,\nas documented in mm/filemap.c:\n\n \u0026quot;If our return value has VM_FAULT_RETRY set, it\u0026apos;s because the mmap_lock\n may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\u0026quot;\n\nWhen this happens, a concurrent munmap() can call remove_vma() and free\nthe vm_area_struct via RCU. The saved \u0026apos;vma\u0026apos; pointer in ocfs2_fault() then\nbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() call\ndereferences it -- a use-after-free.\n\nFix this by saving ip_blkno as a plain integer before calling\nfilemap_fault(), and removing vma from the trace event. Since\nip_blkno is copied by value before the lock can be dropped, it\nremains valid regardless of what happens to the vma or inode\nafterward.(CVE-2026-31597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -\u0026gt; ip_alloc_sem):\nocfs2_unlink\n ocfs2_prepare_orphan_dir\n ocfs2_lookup_lock_orphan_dir\n inode_lock(orphan_dir_inode) \u0026lt;- lock A\n __ocfs2_prepare_orphan_dir\n ocfs2_prepare_dir_for_insert\n ocfs2_extend_dir\n\t ocfs2_expand_inline_dir\n\t down_write(\u0026amp;oi-\u0026gt;ip_alloc_sem) \u0026lt;- Lock B\n\nLock Chain #1 (ip_alloc_sem -\u0026gt; orphan dir inode_lock):\nocfs2_dio_end_io_write\n down_write(\u0026amp;oi-\u0026gt;ip_alloc_sem) \u0026lt;- Lock B\n ocfs2_del_inode_from_orphan()\n inode_lock(orphan_dir_inode) \u0026lt;- Lock A\n\nDeadlock Scenario:\n CPU0 (unlink) CPU1 (dio_end_io_write)\n ------ ------\n inode_lock(orphan_dir_inode)\n down_write(ip_alloc_sem)\n down_write(ip_alloc_sem)\n inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan. So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.(CVE-2026-31598)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections\n\nsyzbot reported a general protection fault in vidtv_psi_desc_assign [1].\n\nvidtv_psi_pmt_stream_init() can return NULL on memory allocation\nfailure, but vidtv_channel_pmt_match_sections() does not check for\nthis. When tail is NULL, the subsequent call to\nvidtv_psi_desc_assign(\u0026amp;tail-\u0026gt;descriptor, desc) dereferences a NULL\npointer offset, causing a general protection fault.\n\nAdd a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean\nup the already-allocated stream chain and return.\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nRIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline]\n vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479\n vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519\n vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]\n vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239(CVE-2026-31599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: sm750fb: fix division by zero in ps_to_hz()\n\nps_to_hz() is called from hw_sm750_crtc_set_mode() without validating\nthat pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO\ncauses a division by zero.\n\nFix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent\nwith other framebuffer drivers.(CVE-2026-31603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()\n\nInitialize le_tmp64 to zero in rtw_BIP_verify() to prevent using\nuninitialized data.\n\nSmatch warns that only 6 bytes are copied to this 8-byte (u64)\nvariable, leaving the last two bytes uninitialized:\n\ndrivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()\nwarn: not copying enough bytes for \u0026apos;\u0026amp;le_tmp64\u0026apos; (8 vs 6 bytes)\n\nInitializing the variable at the start of the function fixes this\nwarning and ensures predictable behavior.(CVE-2026-31626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat\n\nA use-after-free / refcount underflow is possible when the heartbeat\nworker and intel_engine_park_heartbeat() race to release the same\nengine-\u0026gt;heartbeat.systole request.\n\nThe heartbeat worker reads engine-\u0026gt;heartbeat.systole and calls\ni915_request_put() on it when the request is complete, but clears\nthe pointer in a separate, non-atomic step. Concurrently, a request\nretirement on another CPU can drop the engine wakeref to zero, triggering\n__engine_park() -\u0026gt; intel_engine_park_heartbeat(). If the heartbeat\ntimer is pending at that point, cancel_delayed_work() returns true and\nintel_engine_park_heartbeat() reads the stale non-NULL systole pointer\nand calls i915_request_put() on it again, causing a refcount underflow:\n\n```\n\u0026lt;4\u0026gt; [487.221889] Workqueue: i915-unordered engine_retire [i915]\n\u0026lt;4\u0026gt; [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0\n...\n\u0026lt;4\u0026gt; [487.222707] Call Trace:\n\u0026lt;4\u0026gt; [487.222711] \u0026lt;TASK\u0026gt;\n\u0026lt;4\u0026gt; [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]\n\u0026lt;4\u0026gt; [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]\n\u0026lt;4\u0026gt; [487.223566] __engine_park+0xb9/0x650 [i915]\n\u0026lt;4\u0026gt; [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]\n\u0026lt;4\u0026gt; [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]\n\u0026lt;4\u0026gt; [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]\n\u0026lt;4\u0026gt; [487.225238] intel_context_exit+0xf1/0x1b0 [i915]\n\u0026lt;4\u0026gt; [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]\n\u0026lt;4\u0026gt; [487.226178] i915_request_retire+0x1c/0x40 [i915]\n\u0026lt;4\u0026gt; [487.226625] engine_retire+0x122/0x180 [i915]\n\u0026lt;4\u0026gt; [487.227037] process_one_work+0x239/0x760\n\u0026lt;4\u0026gt; [487.227060] worker_thread+0x200/0x3f0\n\u0026lt;4\u0026gt; [487.227068] ? __pfx_worker_thread+0x10/0x10\n\u0026lt;4\u0026gt; [487.227075] kthread+0x10d/0x150\n\u0026lt;4\u0026gt; [487.227083] ? __pfx_kthread+0x10/0x10\n\u0026lt;4\u0026gt; [487.227092] ret_from_fork+0x3d4/0x480\n\u0026lt;4\u0026gt; [487.227099] ? __pfx_kthread+0x10/0x10\n\u0026lt;4\u0026gt; [487.227107] ret_from_fork_asm+0x1a/0x30\n\u0026lt;4\u0026gt; [487.227141] \u0026lt;/TASK\u0026gt;\n```\n\nFix this by replacing the non-atomic pointer read + separate clear with\nxchg() in both racing paths. xchg() is a single indivisible hardware\ninstruction that atomically reads the old pointer and writes NULL. This\nguarantees only one of the two concurrent callers obtains the non-NULL\npointer and performs the put, the other gets NULL and skips it.\n\n(cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)(CVE-2026-31656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: reject oversized dirents in page cache\n\nfuse_add_dirent_to_cache() computes a serialized dirent size from the\nserver-controlled namelen field and copies the dirent into a single\npage-cache page. The existing logic only checks whether the dirent fits\nin the remaining space of the current page and advances to a fresh page\nif not. It never checks whether the dirent itself exceeds PAGE_SIZE.\n\nAs a result, a malicious FUSE server can return a dirent with\nnamelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB\npage systems this causes memcpy() to overflow the cache page by 24 bytes\ninto the following kernel page.\n\nReject dirents that cannot fit in a single page before copying them into\nthe readdir cache.(CVE-2026-31694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_helper: pass helper to expect cleanup\n\nnf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()\nto remove expectations belonging to the helper being unregistered.\nHowever, it passes NULL instead of the helper pointer as the data\nargument, so expect_iter_me() never matches any expectation and all\nof them survive the cleanup.\n\nAfter unregister returns, nfnl_cthelper_del() frees the helper\nobject immediately. Subsequent expectation dumps or packet-driven\ninit_conntrack() calls then dereference the freed exp-\u0026gt;helper,\ncausing a use-after-free.\n\nPass the actual helper pointer so expectations referencing it are\nproperly destroyed before the helper object is freed.\n\n BUG: KASAN: slab-use-after-free in string+0x38f/0x430\n Read of size 1 at addr ffff888003b14d20 by task poc/103\n Call Trace:\n string+0x38f/0x430\n vsnprintf+0x3cc/0x1170\n seq_printf+0x17a/0x240\n exp_seq_show+0x2e5/0x560\n seq_read_iter+0x419/0x1280\n proc_reg_read+0x1ac/0x270\n vfs_read+0x179/0x930\n ksys_read+0xef/0x1c0\n Freed by task 103:\n The buggy address is located 32 bytes inside of\n freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)(CVE-2026-43027)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: ensure names are nul-terminated\n\nReject names that lack a \\0 character before feeding them\nto functions that expect c-strings.\n\nFixes tag is the most recent commit that needs this change.(CVE-2026-43028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndcache: Limit the minimal number of bucket to two\n\nThere is an OOB read problem on dentry_hashtable when user sets\n\u0026apos;dhash_entries=1\u0026apos;:\n BUG: unable to handle page fault for address: ffff888b30b774b0\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n Oops: Oops: 0000 [#1] SMP PTI\n RIP: 0010:__d_lookup+0x56/0x120\n Call Trace:\n d_lookup.cold+0x16/0x5d\n lookup_dcache+0x27/0xf0\n lookup_one_qstr_excl+0x2a/0x180\n start_dirop+0x55/0xa0\n simple_start_creating+0x8d/0xa0\n debugfs_start_creating+0x8c/0x180\n debugfs_create_dir+0x1d/0x1c0\n pinctrl_init+0x6d/0x140\n do_one_initcall+0x6d/0x3d0\n kernel_init_freeable+0x39f/0x460\n kernel_init+0x2a/0x260\n\nThere will be only one bucket in dentry_hashtable when dhash_entries is\nset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,\nfollowing process will access more than one buckets(which memory region\nis not allocated) in dentry_hashtable:\n d_lookup\n b = d_hash(hash)\n dentry_hashtable + ((u32)hashlen \u0026gt;\u0026gt; d_hash_shift)\n // The C standard defines the behavior of right shift amounts\n // exceeding the bit width of the operand as undefined. The\n // result of \u0026apos;(u32)hashlen \u0026gt;\u0026gt; d_hash_shift\u0026apos; becomes \u0026apos;hashlen\u0026apos;,\n // so \u0026apos;b\u0026apos; will point to an unallocated memory region.\n hlist_bl_for_each_entry_rcu(b)\n hlist_bl_first_rcu(head)\n h-\u0026gt;first // read OOB!\n\nFix it by limiting the minimal number of dentry_hashtable bucket to two,\nso that \u0026apos;d_hash_shift\u0026apos; won\u0026apos;t exceeds the bit width of type u32.(CVE-2026-43071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-verity: correctly handle dm_bufio_client_create() failure\n\nIf either of the calls to dm_bufio_client_create() in verity_fec_ctr()\nfails, then dm_bufio_client_destroy() is later called with an ERR_PTR()\nargument. That causes a crash. Fix this.(CVE-2026-43132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: delete attr leaf freemap entries when empty\n\nBack in commit 2a2b5932db6758 (\u0026quot;xfs: fix attr leaf header freemap.size\nunderflow\u0026quot;), Brian Foster observed that it\u0026apos;s possible for a small\nfreemap at the end of the end of the xattr entries array to experience\na size underflow when subtracting the space consumed by an expansion of\nthe entries array. There are only three freemap entries, which means\nthat it is not a complete index of all free space in the leaf block.\n\nThis code can leave behind a zero-length freemap entry with a nonzero\nbase. Subsequent setxattr operations can increase the base up to the\npoint that it overlaps with another freemap entry. This isn\u0026apos;t in and of\nitself a problem because the code in _leaf_add that finds free space\nignores any freemap entry with zero size.\n\nHowever, there\u0026apos;s another bug in the freemap update code in _leaf_add,\nwhich is that it fails to update a freemap entry that begins midway\nthrough the xattr entry that was just appended to the array. That can\nresult in the freemap containing two entries with the same base but\ndifferent sizes (0 for the \u0026quot;pushed-up\u0026quot; entry, nonzero for the entry\nthat\u0026apos;s actually tracking free space). A subsequent _leaf_add can then\nallocate xattr namevalue entries on top of the entries array, leading to\ndata loss. But fixing that is for later.\n\nFor now, eliminate the possibility of confusion by zeroing out the base\nof any freemap entry that has zero size. Because the freemap is not\nintended to be a complete index of free space, a subsequent failure to\nfind any free space for a new xattr will trigger block compaction, which\nregenerates the freemap.\n\nIt looks like this bug has been in the codebase for quite a long time.(CVE-2026-43187)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-mdp: Fix error handling in probe function\n\nAdd mtk_mdp_unregister_m2m_device() on the error handling path to prevent\nresource leak.\n\nAdd check for the return value of vpu_get_plat_device() to prevent null\npointer dereference. And vpu_get_plat_device() increases the reference\ncount of the returned platform device. Add platform_device_put() to\nprevent reference leak.(CVE-2026-43207)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: -\u0026gt;d_compare() must not block\n\n... so don\u0026apos;t use __getname() there. Switch it (and ntfs_d_hash(), while\nwe are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash()\nalmost certainly can do with smaller allocations, but let ntfs folks\ndeal with that - keep the allocation size as-is for now.\n\nStop abusing names_cachep in ntfs, period - various uses of that thing\nin there have nothing to do with pathnames; just use k[mz]alloc() and\nbe done with that. For now let\u0026apos;s keep sizes as-in, but AFAICS none of\nthe users actually want PATH_MAX.(CVE-2026-43245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Avoid double-rtnl_lock ELP metric worker\n\nbatadv_v_elp_get_throughput() might be called when the RTNL lock is already\nheld. This could be problematic when the work queue item is cancelled via\ncancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case,\nan rtnl_lock() would cause a deadlock.\n\nTo avoid this, rtnl_trylock() was used in this function to skip the\nretrieval of the ethtool information in case the RTNL lock was already\nheld.\n\nBut for cfg80211 interfaces, batadv_get_real_netdev() was called - which\nalso uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must\nalso be used instead and the lockless version __batadv_get_real_netdev()\nhas to be called.(CVE-2026-43382)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()\n\nIn the drain loop, the local variable \u0026apos;runtime\u0026apos; is reassigned to a\nlinked stream\u0026apos;s runtime (runtime = s-\u0026gt;runtime at line 2157). After\nreleasing the stream lock at line 2169, the code accesses\nruntime-\u0026gt;no_period_wakeup, runtime-\u0026gt;rate, and runtime-\u0026gt;buffer_size\n(lines 2170-2178) \u2014 all referencing the linked stream\u0026apos;s runtime without\nany lock or refcount protecting its lifetime.\n\nA concurrent close() on the linked stream\u0026apos;s fd triggers\nsnd_pcm_release_substream() \u2192 snd_pcm_drop() \u2192 pcm_release_private()\n\u2192 snd_pcm_unlink() \u2192 snd_pcm_detach_substream() \u2192 kfree(runtime).\nNo synchronization prevents kfree(runtime) from completing while the\ndrain path dereferences the stale pointer.\n\nFix by caching the needed runtime fields (no_period_wakeup, rate,\nbuffer_size) into local variables while still holding the stream lock,\nand using the cached values after the lock is released.(CVE-2026-43437)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: alb: fix UAF in rlb_arp_recv during bond up/down\n\nThe ALB RX path may access rx_hashtbl concurrently with bond\nteardown. During rapid bond up/down cycles, rlb_deinitialize()\nfrees rx_hashtbl while RX handlers are still running, leading\nto a null pointer dereference detected by KASAN.\n\nHowever, the root cause is that rlb_arp_recv() can still be accessed\nafter setting recv_probe to NULL, which is actually a use-after-free\n(UAF) issue. That is the reason for using the referenced commit in the\nFixes tag.\n\n[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI\n[ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]\n[ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)\n[ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022\n[ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding]\n[ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6\n 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00\n[ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206\n[ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e\n[ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8\n[ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8\n[ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119\n[ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810\n[ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000\n[ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0\n[ 214.310347] Call Trace:\n[ 214.313070] \u0026lt;IRQ\u0026gt;\n[ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding]\n[ 214.320975] bond_handle_frame+0x166/0xb60 [bonding]\n[ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding]\n[ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710\n[ 214.339199] ? __pfx_arp_process+0x10/0x10\n[ 214.343775] ? sched_balance_find_src_group+0x98/0x630\n[ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10\n[ 214.356513] ? arp_rcv+0x307/0x690\n[ 214.360311] ? __pfx_arp_rcv+0x10/0x10\n[ 214.364499] ? __lock_acquire+0x58c/0xbd0\n[ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0\n[ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10\n[ 214.380743] ? lock_acquire+0x10b/0x140\n[ 214.385026] process_backlog+0x3f1/0x13a0\n[ 214.389502] ? process_backlog+0x3aa/0x13a0\n[ 214.394174] __napi_poll.constprop.0+0x9f/0x370\n[ 214.399233] net_rx_action+0x8c1/0xe60\n[ 214.403423] ? __pfx_net_rx_action+0x10/0x10\n[ 214.408193] ? lock_acquire.part.0+0xbd/0x260\n[ 214.413058] ? sched_clock_cpu+0x6c/0x540\n[ 214.417540] ? mark_held_locks+0x40/0x70\n[ 214.421920] handle_softirqs+0x1fd/0x860\n[ 214.426302] ? __pfx_handle_softirqs+0x10/0x10\n[ 214.431264] ? __neigh_event_send+0x2d6/0xf50\n[ 214.436131] do_softirq+0xb1/0xf0\n[ 214.439830] \u0026lt;/IRQ\u0026gt;\n\nThe issue is reproducible by repeatedly running\nip link set bond0 up/down while receiving ARP messages, where\nrlb_arp_recv() can race with rlb_deinitialize() and dereference\na freed rx_hashtbl entry.\n\nFix this by setting recv_probe to NULL and then calling\nsynchronize_net() to wait for any concurrent RX processing to finish.\nThis ensures that no RX handler can access rx_hashtbl after it is freed\nin bond_alb_deinitialize().(CVE-2026-45970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: avoid early lgr access in smc_clc_wait_msg\n\nA CLC decline can be received while the handshake is still in an early\nstage, before the connection has been associated with a link group.\n\nThe decline handling in smc_clc_wait_msg() updates link-group level sync\nstate for first-contact declines, but that state only exists after link\ngroup setup has completed. Guard the link-group update accordingly and\nkeep the per-socket peer diagnosis handling unchanged.\n\nThis preserves the existing sync_err handling for established link-group\ncontexts and avoids touching link-group state before it is available.(CVE-2026-46027)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels\n\nseg6_input_core() and rpl_input() call ip6_route_input() which sets a\nNOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking\ndst_hold() unconditionally.\nOn PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can\nrelease the underlying pcpu_rt between the lookup and the caching\nthrough a concurrent FIB lookup on a shared nexthop.\nSimplified race sequence:\n\n ksoftirqd/X higher-prio task (same CPU X)\n ----------- --------------------------------\n seg6_input_core(,skb)/rpl_input(skb)\n dst_cache_get()\n -\u0026gt; miss\n ip6_route_input(skb)\n -\u0026gt; ip6_pol_route(,skb,flags)\n [RT6_LOOKUP_F_DST_NOREF in flags]\n -\u0026gt; FIB lookup resolves fib6_nh\n [nhid=N route]\n -\u0026gt; rt6_make_pcpu_route()\n [creates pcpu_rt, refcount=1]\n pcpu_rt-\u0026gt;sernum = fib6_sernum\n [fib6_sernum=W]\n -\u0026gt; cmpxchg(fib6_nh.rt6i_pcpu,\n NULL, pcpu_rt)\n [slot was empty, store succeeds]\n -\u0026gt; skb_dst_set_noref(skb, dst)\n [dst is pcpu_rt, refcount still 1]\n\n rt_genid_bump_ipv6()\n -\u0026gt; bumps fib6_sernum\n [fib6_sernum from W to Z]\n ip6_route_output()\n -\u0026gt; ip6_pol_route()\n -\u0026gt; FIB lookup resolves fib6_nh\n [nhid=N]\n -\u0026gt; rt6_get_pcpu_route()\n pcpu_rt-\u0026gt;sernum != fib6_sernum\n [W \u0026lt;\u0026gt; Z, stale]\n -\u0026gt; prev = xchg(rt6i_pcpu, NULL)\n -\u0026gt; dst_release(prev)\n [prev is pcpu_rt,\n refcount 1-\u0026gt;0, dead]\n\n dst = skb_dst(skb)\n [dst is the dead pcpu_rt]\n dst_cache_set_ip6(dst)\n -\u0026gt; dst_hold() on dead dst\n -\u0026gt; WARN / use-after-free\n\nFor the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without\nPREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release\nthe pcpu_rt. Shared nexthop objects provide such a path, as two routes\npointing to the same nhid share the same fib6_nh and its rt6i_pcpu\nentry.\n\nFix seg6_input_core() and rpl_input() by calling skb_dst_force() after\nip6_route_input() to force the NOREF dst into a refcounted one before\ncaching.\nThe output path is not affected as ip6_route_output() already returns a\nrefcounted dst.(CVE-2026-46099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix unlocked call to hns_roce_qp_remove()\n\nSashiko points out that hns_roce_qp_remove() requires the caller to hold\nlocks. The error flow in hns_roce_create_qp_common() doesn\u0026apos;t hold those\nlocks for the error unwind so it risks corrupting memory.\n\nGrab the same locks the other two callers use.(CVE-2026-46112)\n\nIn the Linux kernel, improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.(CVE-2026-46174)\n\nIn the Linux kernel\u0026apos;s RDMA/vmw_pvrdma driver, the error path of pvrdma_alloc_ucontext() calls pvrdma_uar_free(), but pvrdma_dealloc_ucontext() already calls pvrdma_uar_free() internally, causing a double free during error handling, which may lead to kernel crash or memory corruption.(CVE-2026-46189)\n\nIn the Linux kernel, when Extended Sequence Number (ESN) is enabled, the AH (Authentication Header) module incorrectly reconstructs the temporary auth/ICV layout in async hash callbacks, omitting the 4-byte seqhi slot for ESN high bits. This causes wrong byte copying/comparison on both IPv4 and IPv6 paths when using an async AH implementation, leading to 100% packet loss. For example, in UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails. After the fix, offsets are corrected and ping succeeds.(CVE-2026-46193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm: fix a buffer overflow in ioctl processing\n\nTony Asleson (using Claude) found a buffer overflow in dm-ioctl in the\nfunction retrieve_status:\n\n1. The code in retrieve_status checks that the output string fits into\n the output buffer and writes the output string there\n2. Then, the code aligns the \u0026quot;outptr\u0026quot; variable to the next 8-byte\n boundary:\n\toutptr = align_ptr(outptr);\n3. The alignment doesn\u0026apos;t check overflow, so outptr could point past the\n buffer end\n4. The \u0026quot;for\u0026quot; loop is iterated again, it executes:\n\tremaining = len - (outptr - outbuf);\n5. If \u0026quot;outptr\u0026quot; points past \u0026quot;outbuf + len\u0026quot;, the arithmetics wraps around\n and the variable \u0026quot;remaining\u0026quot; contains unusually high number\n6. With \u0026quot;remaining\u0026quot; being high, the code writes more data past the end of\n the buffer\n\nLuckily, this bug has no security implications because:\n1. Only root can issue device mapper ioctls\n2. The commonly used libraries that communicate with device mapper\n (libdevmapper and devicemapper-rs) use buffer size that is aligned to\n 8 bytes - thus, \u0026quot;outptr = align_ptr(outptr)\u0026quot; can\u0026apos;t overshoot the input\n buffer and the bug can\u0026apos;t happen accidentally(CVE-2026-46294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix pedit partial COW leading to page cache corruption\n\ntcf_pedit_act() computes the COW range for skb_ensure_writable()\nonce before the key loop using tcfp_off_max_hint, but the hint does\nnot account for the runtime header offset added by typed keys. This\ncan leave part of the write region un-COW\u0026apos;d.\n\nFix by moving skb_ensure_writable() inside the per-key loop where\nthe actual write offset is known, and add overflow checking on the\noffset arithmetic. For negative offsets (e.g. Ethernet header edits\nat ingress), use skb_cow() to COW the headroom instead. Guard\noffset_valid() against INT_MIN, where negation is undefined.(CVE-2026-46331)",
"id": "OESA-2026-2754",
"modified": "2026-08-06T11:11:40Z",
"published": "2026-06-24T11:11:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31507"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31585"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31596"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31598"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31603"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31626"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43027"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43187"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43207"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43382"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43437"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46027"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46189"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46193"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46331"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-38702",
"CVE-2025-40349",
"CVE-2026-23058",
"CVE-2026-31507",
"CVE-2026-31580",
"CVE-2026-31585",
"CVE-2026-31586",
"CVE-2026-31596",
"CVE-2026-31597",
"CVE-2026-31598",
"CVE-2026-31599",
"CVE-2026-31603",
"CVE-2026-31626",
"CVE-2026-31656",
"CVE-2026-31694",
"CVE-2026-43027",
"CVE-2026-43028",
"CVE-2026-43071",
"CVE-2026-43132",
"CVE-2026-43187",
"CVE-2026-43207",
"CVE-2026-43245",
"CVE-2026-43382",
"CVE-2026-43437",
"CVE-2026-45970",
"CVE-2026-46027",
"CVE-2026-46099",
"CVE-2026-46112",
"CVE-2026-46174",
"CVE-2026-46189",
"CVE-2026-46193",
"CVE-2026-46294",
"CVE-2026-46331"
]
}
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.