OESA-2026-2754

The 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 doregisterframebuffer()

The current implementation may lead to buffer overflow when: 1. Unregistration creates NULL gaps in registeredfb[] 2. All array slots become occupied despite numregisteredfb < FBMAX 3. The registration loop exceeds array bounds

Add boundary check to prevent registeredfb[FBMAX] access.(CVE-2025-38702)

In the Linux kernel, the following vulnerability has been resolved:

hfs: validate record offset in hfsplusbmapalloc

hfsplusbmapalloc can trigger a crash if a record offset or length is larger than node_size

[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplusbmapalloc+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] dumpstacklvl+0x53/0x70 [ 15.266173] printreport+0xd0/0x660 [ 15.266181] kasanreport+0xce/0x100 [ 15.266185] hfsplusbmapalloc+0x887/0x8b0 [ 15.266208] hfsbtreeincheight.isra.0+0xd5/0x7c0 [ 15.266217] hfsplusbrec_insert+0x870/0xb00 [ 15.266222] __hfsplusextwrite_extent+0x428/0x570 [ 15.266225] __hfsplusextcacheextent+0x5e/0x910 [ 15.266227] hfsplusextreadextent+0x1b2/0x200 [ 15.266233] hfsplusfileextend+0x5a7/0x1000 [ 15.266237] hfsplusgetblock+0x12b/0x8c0 [ 15.266238] __blockwritebeginint+0x36b/0x12c0 [ 15.266251] blockwritebegin+0x77/0x110 [ 15.266252] contwritebegin+0x428/0x720 [ 15.266259] hfspluswritebegin+0x51/0x100 [ 15.266262] contwritebegin+0x272/0x720 [ 15.266270] hfspluswritebegin+0x51/0x100 [ 15.266274] genericperformwrite+0x321/0x750 [ 15.266285] genericfilewriteiter+0xc3/0x310 [ 15.266289] _kernelwriteiter+0x2fd/0x800 [ 15.266296] dumpuserrange+0x2ea/0x910 [ 15.266301] elfcoredump+0x2a94/0x2ed0 [ 15.266320] vfscoredump+0x1d85/0x45e0 [ 15.266349] getsignal+0x12e3/0x1990 [ 15.266357] archdosignalorrestart+0x89/0x580 [ 15.266362] irqentryexittousermode+0xab/0x110 [ 15.266364] asmexcpagefault+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 hfsplusbmapalloc 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 hfsbreclenoff

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 isbnodeoffsetvalid and checkandcorrectrequestedlength to hfsplusfs.h, as they may be required by other functions.(CVE-2025-40349)

In the Linux kernel, the following vulnerability has been resolved:

can: emsusb: emsusbreadbulk_callback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulk_callback(): fix URB memory leak").

In emsusbopen(), the URBs for USB-in transfers are allocated, added to the dev->rxsubmitted anchor and submitted. In the complete callback emsusbreadbulkcallback(), the URBs are processed and resubmitted. In emsusbclose() the URBs are freed by calling usbkillanchoredurbs(&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 emsusbclose().

Fix the memory leak by anchoring the URB in the emsusbreadbulkcallback() 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 smcspdpriv when tee() duplicates splice pipe buffer

smcrxsplice() allocates one smcspdpriv per pipebuffer and stores the pointer in pipebuffer.private. The pipebufoperations for these buffers used .get = genericpipebufget, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smcspdpriv pointer itself was not handled, so after tee() both the original and the cloned pipebuffer share the same smcspdpriv *.

When both pipes are subsequently released, smcrxpipebufrelease() is called twice against the same object:

1st call: kfree(priv) sockput(sk) smcrxupdatecons() [correct] 2nd call: kfree(priv) sockput(sk) smcrxupdatecons() [UAF]

KASAN reports a slab-use-after-free in smcrxpipebufrelease(), which then escalates to a NULL-pointer dereference and kernel panic via smcrxupdate_consumer() when it chases the freed priv->smc pointer:

BUG: KASAN: slab-use-after-free in smcrxpipebufrelease+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smcsplicetee_/74 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x650 kasanreport+0xc6/0x100 smcrxpipebufrelease+0x78/0x2a0 freepipeinfo+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smcrxupdateconsumer+0x8d/0x350 Call Trace: <TASK> smcrxpipebufrelease+0x121/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 __fput+0x1c6/0x490 __x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception

Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smcrxupdatecons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smcspd_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 splicepipeto_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 cacheddev.sbbio 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->sbbio has been freed. We know that cacheddev is only freed when it is stopped.

Since sbbio is a part of struct cacheddev, 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 sbwrite to complete in cacheddev_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 vidtvpsiservicedescinit [1].

When vidtvstartstreaming() fails inside vidtvstartfeed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent startfeed calls see nfeeds > 1 and skip starting the mux, while stopfeed 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): vidtvpsiservicedescinit+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtvpsi.c:288 vidtvchannels302minit+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtvchannel.c:83 vidtvchannelsinit+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtvchannel.c:524 vidtvmuxinit+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtvmux.c:518 vidtvstartstreaming drivers/media/test-drivers/vidtv/vidtvbridge.c:194 [inline] vidtvstartfeed+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 cgwbreleaseworkfn()

cgwbreleaseworkfn() calls cssput(wb->blkcgcss) and then later accesses wb->blkcgcss again via blkcgunpinonline(). If cssput() drops the last reference, the blkcg can be freed asynchronously (cssfreerworkfn -> blkcgcssfree -> kfree) before blkcgunpinonline() dereferences the pointer to access blkcg->onlinepin, resulting in a use-after-free:

BUG: KASAN: slab-use-after-free in blkcgunpinonline (./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: cgwbrelease cgwbreleaseworkfn Call Trace: <TASK> blkcgunpinonline (./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) cgwbreleaseworkfn (mm/backing-dev.c:629) processscheduled_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) cssfreerworkfn (kernel/cgroup/cgroup.c:5542) processscheduled_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/reproblkcguaf.sh

(The race window is narrow. To make it easily reproducible, inject a msleep(100) between cssput() and blkcgunpinonline() in cgwbrelease_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.)

Fix this by moving blkcgunpinonline() before cssput(), so the cgwb's CSS reference keeps the blkcg alive while blkcgunpin_online() accesses it.(CVE-2026-31586)

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: handle invalid dinode in ocfs2groupextend

[BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2groupextend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfsioctl fs/ioctl.c:51 [inline] __dosysioctl fs/ioctl.c:597 [inline] __sesysioctl fs/ioctl.c:583 [inline] _x64sysioctl+0x197/0x1e0 fs/ioctl.c:583 x64syscall+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x93/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e ...

[CAUSE] ocfs2groupextend() assumes that the global bitmap inode block returned from ocfs2inodelock() 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 ocfs2groupextend(). 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 ocfs2fault() when VMFAULT_RETRY

filemapfault() may drop the mmaplock before returning VMFAULTRETRY, as documented in mm/filemap.c:

"If our return value has VMFAULTRETRY set, it's because the mmaplock may be dropped before doing I/O or by lockfoliomaybedrop_mmap()."

When this happens, a concurrent munmap() can call removevma() and free the vmareastruct via RCU. The saved 'vma' pointer in ocfs2fault() then becomes a dangling pointer, and the subsequent traceocfs2fault() call dereferences it -- a use-after-free.

Fix this by saving ipblkno as a plain integer before calling filemapfault(), 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 dioendio_write

ocfs2unlink takes orphan dir inodelock first and then ipallocsem, while in ocfs2dioendiowrite, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2sysfilelockkey[ORPHANDIRSYSTEMINODE] and ocfs2fileipallocsem_key.

Lock Chain #0 (orphan dir inodelock -> ipallocsem): ocfs2unlink ocfs2prepareorphandir ocfs2lookuplockorphandir inodelock(orphandirinode) <- lock A _ocfs2prepareorphandir ocfs2preparedirforinsert ocfs2extenddir ocfs2expandinlinedir downwrite(&oi->ipallocsem) <- Lock B

Lock Chain #1 (ipallocsem -> orphan dir inodelock): ocfs2dioendiowrite downwrite(&oi->ipallocsem) <- Lock B ocfs2delinodefromorphan() inodelock(orphandir_inode) <- Lock A

Deadlock Scenario: CPU0 (unlink) CPU1 (dioendiowrite) ------ ------ inodelock(orphandirinode) downwrite(ipallocsem) downwrite(ipallocsem) inodelock(orphandir_inode)

Since ipallocsem is to protect allocation changes, which is unrelated with operations in ocfs2delinodefromorphan. So move ocfs2delinodefromorphan out of ipallocsem to fix the deadlock.(CVE-2026-31598)

In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: fix NULL pointer dereference in vidtvchannelpmtmatchsections

syzbot reported a general protection fault in vidtvpsidesc_assign [1].

vidtvpsipmtstreaminit() can return NULL on memory allocation failure, but vidtvchannelpmtmatchsections() does not check for this. When tail is NULL, the subsequent call to vidtvpsidesc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault.

Add a NULL check after vidtvpsipmtstreaminit(). 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:vidtvpsidescassign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtvpsi.c:629 Call Trace: <TASK> vidtvchannelpmtmatchsections drivers/media/test-drivers/vidtv/vidtvchannel.c:349 [inline] vidtvchannelsiinit+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtvchannel.c:479 vidtvmuxinit+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtvmux.c:519 vidtvstartstreaming drivers/media/test-drivers/vidtv/vidtvbridge.c:194 [inline] vidtvstartfeed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtvbridge.c:239(CVE-2026-31599)

In the Linux kernel, the following vulnerability has been resolved:

staging: sm750fb: fix division by zero in pstohz()

pstohz() is called from hwsm750crtcsetmode() 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 lynxfbopscheck_var(), consistent with other framebuffer drivers.(CVE-2026-31603)

In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8723bs: initialize letmp64 in rtwBIP_verify()

Initialize letmp64 to zero in rtwBIP_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/rtwsecurity.c:1308 rtwBIPverify() warn: not copying enough bytes for '&letmp64' (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 intelenginepark_heartbeat

A use-after-free / refcount underflow is possible when the heartbeat worker and intelenginepark_heartbeat() race to release the same engine->heartbeat.systole request.

The heartbeat worker reads engine->heartbeat.systole and calls i915requestput() 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 _enginepark() -> intelengineparkheartbeat(). If the heartbeat timer is pending at that point, canceldelayedwork() returns true and intelengineparkheartbeat() reads the stale non-NULL systole pointer and calls i915requestput() 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

fuseadddirenttocache() 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: nfconntrackhelper: pass helper to expect cleanup

nfconntrackhelperunregister() calls nfctexpectiteratedestroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expectiter_me() never matches any expectation and all of them survive the cleanup.

After unregister returns, nfnlcthelperdel() 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 seqprintf+0x17a/0x240 expseqshow+0x2e5/0x560 seqreaditer+0x419/0x1280 procregread+0x1ac/0x270 vfsread+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 dentryhashtable when user sets 'dhashentries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:dlookup+0x56/0x120 Call Trace: dlookup.cold+0x16/0x5d lookupdcache+0x27/0xf0 lookuponeqstrexcl+0x2a/0x180 startdirop+0x55/0xa0 simplestartcreating+0x8d/0xa0 debugfsstartcreating+0x8c/0x180 debugfscreatedir+0x1d/0x1c0 pinctrlinit+0x6d/0x140 dooneinitcall+0x6d/0x3d0 kernelinitfreeable+0x39f/0x460 kernelinit+0x2a/0x260

There will be only one bucket in dentryhashtable when dhashentries is set as one, and dhashshift is calculated as 32 by dcacheinit(). Then, following process will access more than one buckets(which memory region is not allocated) in dentryhashtable: dlookup b = dhash(hash) dentryhashtable + ((u32)hashlen >> dhashshift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> dhashshift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlistblforeachentryrcu(b) hlistblfirst_rcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentryhashtable bucket to two, so that 'dhash_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 dmbufioclient_create() failure

If either of the calls to dmbufioclientcreate() in verityfecctr() fails, then dmbufioclientdestroy() 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 leafadd that finds free space ignores any freemap entry with zero size.

However, there's another bug in the freemap update code in leafadd, 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 leafadd 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 mtkmdpunregisterm2mdevice() on the error handling path to prevent resource leak.

Add check for the return value of vpugetplatdevice() to prevent null pointer dereference. And vpugetplatdevice() increases the reference count of the returned platform device. Add platformdeviceput() 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 ntfsdhash(), while we are at it) to kmalloc(PATHMAX, GFPNOWAIT). Yes, ntfsdhash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now.

Stop abusing namescachep 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 PATHMAX.(CVE-2026-43245)

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: Avoid double-rtnl_lock ELP metric worker

batadvvelpgetthroughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via canceldelayedworksync() in batadvvelpifacedisable(). In this case, an rtnllock() 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, batadvgetrealnetdev() was called - which also uses rtnllock(). The approach for __ethtoolgetlink_ksettings() must also be used instead and the lockless version _batadvgetrealnetdev() 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 sndpcmdrain()

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->noperiodwakeup, 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 sndpcmreleasesubstream() → sndpcmdrop() → pcmreleaseprivate() → sndpcmunlink() → sndpcmdetachsubstream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer.

Fix by caching the needed runtime fields (noperiodwakeup, 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 rlbarprecv during bond up/down

The ALB RX path may access rxhashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlbdeinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN.

However, the root cause is that rlbarprecv() 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:rlbarprecv+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] ? __pfxrlbarp_recv+0x10/0x10 [bonding] [ 214.320975] bondhandleframe+0x166/0xb60 [bonding] [ 214.326537] ? __pfxbondhandle_frame+0x10/0x10 [bonding] [ 214.332680] __netifreceiveskb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfxarpprocess+0x10/0x10 [ 214.343775] ? sched_balancefindsrcgroup+0x98/0x630 [ 214.349513] ? pfxnetifreceiveskbcore.constprop.0+0x10/0x10 [ 214.356513] ? arprcv+0x307/0x690 [ 214.360311] ? __pfxarprcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netifreceivelock_acquire+0x58c/0xbd0 [ 214.368975] __netifreceiveskbonecore+0xae/0x1b0 [ 214.374518] ? pfxetif_receiveskbonecore+0x10/0x10 [ 214.380743] ? lockacquire+0x10b/0x140 [ 214.385026] processbacklog+0x3f1/0x13a0 [ 214.389502] ? processbacklog+0x3aa/0x13a0 [ 214.394174] __napipoll.constprop.0+0x9f/0x370 [ 214.399233] netrx_action+0x8c1/0xe60 [ 214.403423] ? __pfxnetrx_action+0x10/0x10 [ 214.408193] ? lockacquire.part.0+0xbd/0x260 [ 214.413058] ? schedclockcpu+0x6c/0x540 [ 214.417540] ? markheldlocks+0x40/0x70 [ 214.421920] handlesoftirqs+0x1fd/0x860 [ 214.426302] ? __pfxhandlesoftirqs+0x10/0x10 [ 214.431264] ? _neigheventsend+0x2d6/0xf50 [ 214.436131] dosoftirq+0xb1/0xf0 [ 214.439830] </IRQ>

The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlbarprecv() can race with rlbdeinitialize() and dereference a freed rxhashtbl entry.

Fix this by setting recvprobe to NULL and then calling synchronizenet() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rxhashtbl after it is freed in bondalb_deinitialize().(CVE-2026-45970)

In the Linux kernel, the following vulnerability has been resolved:

net/smc: avoid early lgr access in smcclcwait_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 smcclcwait_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

seg6inputcore() and rplinput() call ip6routeinput() which sets a NOREF dst on the skb, then pass it to dstcachesetip6() invoking dsthold() unconditionally. On PREEMPTRT, 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) ----------- -------------------------------- seg6inputcore(,skb)/rplinput(skb) dstcacheget() -> miss ip6routeinput(skb) -> ip6polroute(,skb,flags) [RT6LOOKUPFDSTNOREF in flags] -> FIB lookup resolves fib6nh [nhid=N route] -> rt6makepcpuroute() [creates pcpurt, refcount=1] pcpurt->sernum = fib6sernum [fib6sernum=W] -> cmpxchg(fib6nh.rt6ipcpu, NULL, pcpurt) [slot was empty, store succeeds] -> skbdstsetnoref(skb, dst) [dst is pcpurt, 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 (PREEMPTRT without PREEMPTRTNEEDSBHLOCK) and a concurrent task must be able to release the pcpurt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6nh and its rt6ipcpu entry.

Fix seg6inputcore() and rplinput() by calling skbdstforce() after ip6routeinput() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6route_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 hnsroceqp_remove()

Sashiko points out that hnsroceqpremove() requires the caller to hold locks. The error flow in hnsrocecreateqp_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/vmwpvrdma driver, the error path of pvrdmaallocucontext() calls pvrdmauarfree(), but pvrdmadeallocucontext() already calls pvrdmauar_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:

1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there
2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr);
3. The alignment doesn't check overflow, so outptr could point past the buffer end
4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf);
5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number
6. 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

tcfpeditact() computes the COW range for skbensurewritable() once before the key loop using tcfpoffmax_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 skbensurewritable() 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 skbcow() to COW the headroom instead. Guard offsetvalid() against INT_MIN, where negation is undefined.(CVE-2026-46331)