OESA-2026-3317

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/amdgpu: prevent immediate PASID reuse case

PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's.

(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)

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

media: hackrf: fix to not free memory after the device is registered in hackrf_probe()

In hackrf driver, the following race condition occurs:

        CPU0                        CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
                        fd = sys_open("/path/to/dev"); // open hackrf fd
                        ....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
                        sys_ioctl(fd, ...);
                          v4l2_ioctl();
                            video_is_registered() // UAF!!
                        ....
                        sys_close(fd);
                          v4l2_release() // UAF!!
                            hackrf_video_release()
                              kfree(); // DFB!!

When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked.

However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked.

Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet.

And since release() free memory too, race to use-after-free and double-free vuln occur.

To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.(CVE-2026-31576)

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

nilfs2: fix NULL iassocinode dereference in nilfsmdtsavetoshadow_map

The DAT inode's btree node cache (iassocinode) is initialized lazily during btree operations. However, nilfsmdtsavetoshadowmap() assumes iassoc_inode is already initialized when copying dirty pages to the shadow map during GC.

If NILFSIOCTLCLEANSEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, iassoc_inode is NULL leading to a general protection fault.

Fix this by calling nilfsattachbtreenodecache() on the DAT inode in nilfsdatread() at mount time, ensuring iassocinode is always initialized before any GC operation can use it.(CVE-2026-31577)

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

media: as102: fix to not free memory after the device is registered in as102usbprobe()

In as102_usb driver, the following race condition occurs:

        CPU0                        CPU1
as102_usb_probe()
  kzalloc(); // alloc as102_dev_t
  ....
  usb_register_dev();
                        fd = sys_open("/path/to/dev"); // open as102 fd
                        ....
  usb_deregister_dev();
  ....
  kfree(); // free as102_dev_t
  ....
                        sys_close(fd);
                          as102_release() // UAF!!
                            as102_usb_release()
                              kfree(); // DFB!!

When a USB character device registered with usbregisterdev() is later unregistered (via usbderegisterdev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked.

In as102, as102usbprobe() calls usbregisterdev() and then, on an error path, does usbderegisterdev() and frees as102devt right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102release() --> as102usbrelease() and access or free as102dev_t again, occur a race to use-after-free and double-free vuln.

The fix is to never kfree(as102devt) directly once usbregisterdev() has succeeded. After deregistration, defer freeing memory to .release().

In other words, let release() perform the last kfree when the final open FD is closed.(CVE-2026-31578)

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

fs/ntfs3: validate rec->used in journal-replay file record check

checkfilerecord() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths:

DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) changeattrsize: memmove(..., used - PtrOffset(rec, next))

When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall.

This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay

Fix this up by bounding rec->used correctly.

This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement.(CVE-2026-31716)

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

PCI: Fix pcislottrylock() error handling

Commit a4e772898f8b ("PCI: Add missing bridge lock to pcibuslock()") delegates the bridge device's pcidevtrylock() to pcibustrylock() in pcislottrylock(), but it forgets to remove the corresponding pcidevunlock() when pcibustrylock() fails.

Before a4e772898f8b, the code did:

if (!pcidevtrylock(dev)) /* <- lock bridge device / goto unlock; if (dev->subordinate) { if (!pcibustrylock(dev->subordinate)) { pcidevunlock(dev); / <- unlock bridge device */ goto unlock; } }

After a4e772898f8b the bridge-device lock is no longer taken, but the pcidevunlock(dev) on the failure path was left in place, leading to the bug.

This yields one of two errors:

1. A warning that the lock is being unlocked when no one holds it.
2. An incorrect unlock of a lock that belongs to another thread.

Fix it by removing the now-redundant pcidevunlock(dev) on the failure path.

[Same patch later posted by Keith at https://patch.msgid.link/(CVE-2026-43211)

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

bpf: Free reuseport cBPF prog after RCU grace period.

Eulgyu Kim reported the splat below with a repro. [0]

The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group.

The reuseport prog is freed by skreuseportprogfree(). bpfprogput() is called for "e"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpfreleaseorigfilter() and bpfprogfree().

If a reuseport prog is detached from the setsockopt() path (reuseportattachprog() or reuseportdetachprog()), skreuseportprog_free() is called without waiting for RCU readers to complete, resulting in various bugs.

Let's defer freeing the reuseport cBPF prog after one RCU grace period.

Note "e"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpfprogput_deferred() and _bpfprogputnoref().

Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 reuseportselectsock+0xedc/0x1220 net/core/sockreuseport.c:596 udp4lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4liblookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4liblookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4librcv+0x1312/0x2620 net/ipv4/udp.c:2752 ipprotocoldeliverrcu+0x282/0x440 net/ipv4/ipinput.c:207 iplocaldeliverfinish+0x3bb/0x6f0 net/ipv4/ipinput.c:241 NFHOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NFHOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netifreceiveskbonecore net/core/dev.c:6181 [inline] __netifreceiveskb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napipoll+0xae/0x340 net/core/dev.c:7709 napipoll net/core/dev.c:7772 [inline] netrxaction+0x5d7/0xf50 net/core/dev.c:7929 handlesoftirqs+0x22b/0x870 kernel/softirq.c:622 dosoftirq+0x76/0xd0 kernel/softirq.c:523 </IRQ> <TASK> __localbhenableip+0xf8/0x130 kernel/softirq.c:450 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlock_bh include/linux/rcupdate.h:924 [inline] __devqueuexmit+0x1dd7/0x3710 net/core/dev.c:4890 neighoutput include/net/neighbour.h:556 [inline] ipfinishoutput2+0xca9/0x1070 net/ipv4/ipoutput.c:237 NFHOOKCOND include/linux/netfilter.h:307 [inline] ipoutput+0x29f/0x450 net/ipv4/ipoutput.c:438 ipsendskb+0x45/0xc0 net/ipv4/ipoutput.c:1508 udpsendskb+0xb04/0x1510 net/ipv4/udp.c:1195 udpsendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 socksendmsgnosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __dosyssendto net/socket.c:2213 [inline] __sesyssendto net/socket.c:2209 [inline] _x64syssendto+0xde/0x100 net/socket.c:2209 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x160/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---(CVE-2026-52910)

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

nvmet-tcp: propagate nvmettcpbuildpduiovec() errors to its callers

Currently, when nvmettcpbuildpduiovec() detects an out-of-bounds PDU length or offset, it triggers nvmettcpfatalerror(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recvmsg.msg_iter was left uninitialized.

Callers such as nvmettcphandleh2cdatapdu() proceed to blindly overwrite the queue state with queue->rcvstate = NVMETTCPRECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator.

Fix this by shifting the error handling responsibility to the callers.(CVE-2026-52989)

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

Bluetooth: RFCOMM: hold listener socket in rfcommconnectind()

rfcommgetsockbychannel() scans rfcommsklist under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcommconnectind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.

The buggy scenario involves two paths, with each column showing the order within that path:

rfcommconnectind(): listener close: 1. Find parent in 1. close() enters rfcommgetsockbychannel() rfcommsockrelease(). 2. Drop rfcommsklist.lock 2. rfcommsockshutdown() without pinning parent. closes the listener. 3. Call locksock(parent) and 3. rfcommsockkill() btacceptenqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call skstate_change().

If close wins the race, parent can be freed before rfcommconnectind() reaches locksock(), btaccept_enqueue(), or the deferred-setup callback.

Take a reference on the listener before leaving rfcommsklist.lock. After locksock() succeeds, recheck that it is still in BTLISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.

KASAN reported a slab-use-after-free in locksocknested() from rfcommconnectind(), with the freeing stack going through rfcommsockkill() and rfcommsockrelease().(CVE-2026-53256)

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

btrfs: only release the dirty pages io tree after successful writes

[WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time:

BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanuptransaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidateandcheckbtreefolios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidateandcheckbtreefolios+0xfd/0x1ca [btrfs] Call Trace: <TASK> closectree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] genericshutdownsuper+0x89/0x1a0 killanonsuper+0x16/0x40 btrfskillsuper+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivatelockedsuper+0x2d/0xb0 cleanupmnt+0xdc/0x140 taskworkrun+0x5a/0xa0 exittousermodeloop+0x123/0x4b0 dosyscall64+0x243/0x7c0 entrySYSCALL64after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7

I'm using a stripped down version, which seems to trigger the warning more reliably:

fsstresspid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clearwarnonce mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & fsstresspid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $fsstresspid unset fsstresspid umount $mnt

if dmesg | grep -q "WARNING"; then
    fail
fi

}

for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done

[CAUSE] Inside btrfswriteandwaittransaction(), we first try to write all dirty ebs, then wait for them to finish.

After that we call btrfsextentiotreerelease() to free all extent states from dirty_pages io tree.

However if we hit an error from btrfswritemarkedextent(), then we still call btrfsextentiotreerelease() to clear that dirtypages io tree, which may contain dirty records that we haven't yet submitted.

Furthermore, the later transaction cleanup path will utilize that dirtypages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidatebtree_folios(). ---truncated---(CVE-2026-53284)

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

udf: reject descriptors with oversized CRC length

udfreadtagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable.

Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block.(CVE-2026-53369)

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

drm/amdgpu/vce: Prevent partial address patches

In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW.(CVE-2026-53375)

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

ksmbd: fix out-of-bounds read in smbcheckperm_dacl()

The permission-check ACE walk in smbcheckpermdacl() validates the ACE header size and caps sid.numsubauth at SIDMAXSUBAUTHORITIES, but it never checks that ace->size is actually large enough to contain numsubauth sub-authorities before compare_sids() dereferences them.

CIFSSIDBASESIZE covers the SID header up to but excluding the subauth[] array, and offsetof(struct smbace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. comparesids() then reads ace->sid.subauth[i] for i < min(localsid->numsubauth, ace->sid.numsubauth). The local comparison SIDs (sideveryone, sidunixNFSmode, and the idtosid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read.

A crafted ACE with size == 16 and numsubauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SIDMAXSUBAUTHORITIES * sizeof(_le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbdvfsgetsdxattr() into a buffer sized exactly to the on-disk data (kzalloc(sdsize) in ndrdecodev4ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2SETINFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs.

Add the missing numsubauth-versus-acesize check, mirroring the identical guards already present in the sibling parsers parsedacl() and smbinherit_dacl().(CVE-2026-53390)

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

nfsd: release layout stid on setlease failure

nfs4allocstid() publishes the new stid into cl->clstateids via idralloccyclic() under cllock before returning to nfsd4alloclayoutstateid(). When nfsd4layoutsetlease() then fails, the error path frees the layout stateid directly with kmemcachefree() without ever calling idrremove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer.

The correct teardown for an IDR-published stid is nfs4putstid(), which removes the IDR slot under cllock, dispatches scfree (nfsd4freelayoutstateid) to release ls->lsfile via nfsd4closelayout(), and drops the nfs4_file reference in its tail.

A second issue blocks that switch: nfsd4freelayoutstateid() unconditionally inspects ls->lsfencework via delayedworkpending() under lslock, but INITDELAYEDWORK(&ls->lsfencework, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work.

nfsd4_alloc_layout_stateid()
  nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */
  nfsd4_layout_setlease()     /* fails */
    nfs4_put_stid()
      nfsd4_free_layout_stateid()
        delayed_work_pending(&ls->ls_fence_work)  /* needs INIT */
        nfsd4_close_layout()  /* nfsd_file_put(ls->ls_file) */
      put_nfs4_file()

Fix by hoisting the lsfenced / lsfencedelay / INITDELAYEDWORK initialization above the nfsd4layoutsetlease() call, and replace the manual nfsdfileput + putnfs4file + kmemcachefree cleanup with a single nfs4put_stid(stp).(CVE-2026-53399)

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

KVM: SVM: Fix page overflow in sevdbgcrypt() for ENCRYPT path

In sevdbgcrypt(), the per-iteration transfer length is bounded by the source page offset (PAGESIZE - soff) but not by the destination page offset (PAGESIZE - doff). When doff > soff, the encrypt path (__sevdbgencryptuser) performs a read-modify-write using a single-page intermediate buffer (dsttpage):

1. _sevdbgdecrypt() expands the size to roundup(len + (doff & 15), 16) before issuing the PSP command. If len + (doff & 15) > PAGESIZE, the PSP writes beyond the end of the 4096-byte dsttpage allocation.

2. The subsequent memcpy()/copyfromuser() into pageaddress(dsttpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition.

Trigger example: soff = 0, doff = 1, debug.len = PAGESIZE - the PSP is instructed to write roundup(4097, 16) = 4112 bytes to a 4096-byte buffer.

Fix by also bounding len by (PAGESIZE - doff), the same check that sevsendupdate_data() already performs for its single-page guest region.

================================================================== BUG: KASAN: slab-use-after-free in sevdbgcrypt+0x993/0xd10 [kvmamd] Write of size 4095 at addr ff110062293bb009 by task sevdbg_test/228214

CPU: 96 UID: 0 PID: 228214 Comm: sevdbgtest Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: <TASK> dumpstacklvl+0x54/0x70 printreport+0xbc/0x260 kasanreport+0xa2/0xd0 kasancheckrange+0x25f/0x2c0 __asanmemcpy+0x40/0x70 sevdbgcrypt+0x993/0xd10 [kvmamd] sevmemencioctl+0x33c/0x450 [kvmamd] kvmvmioctl+0x65d/0x6d0 [kvm] __sesysioctl+0xb2/0x100 dosyscall64+0xe8/0x870 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected

Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint

sean: add sample KASAN splat, Fixes, and stable@

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

ocfs2: reject oversized group bitmap descriptors

ocfs2validategdparent() only bounds bgbits against the parent allocator's chain geometry. A malicious descriptor can still claim a bgsize/bgbits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap.

Add a physical-cap check based on ocfs2groupbitmapsize() for the parent allocator type and reject descriptors whose bgsize or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used.

Validation reproduced this kernel report: KASAN use-after-free in findnextbit+0x7f/0xc0 Read of size 8 Call trace: dumpstacklvl+0x66/0xa0 (?:?) printreport+0xd0/0x630 (?:?) findnextbit+0x7f/0xc0 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) __virtaddrvalid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2findmaxcontigfreebits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2blockgroupsetbits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2clustergroupsearch+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2bgdiscontigfixresult+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2searchchain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) getpagefromfreelist+0x70e/0x2370 (?:?) lockrelease+0xc6/0x290 (?:?) dorawspinunlock+0x9a/0x100 (?:?) kasanunpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) getpagefromfreelist+0x83d/0x2370 (?:?) ocfs2claimsuballocbits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) scheddomainsnumamasksclear+0x70/0xd0 (?:?) checkirqusage+0xe8/0xb70 (?:?) __ocfs2claimclusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) checkpath+0x24/0x50 (?:?) rcuiswatching+0x20/0x50 (?:?) checkprevadd+0xfd/0xd00 (?:?) ocfs2addclustersin_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __foliobatchaddandmove+0x1f5/0x3d0 (?:?) ocfs2addinodedata+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemapaddfolio+0x105/0x1f0 (?:?) ocfs2writebeginnolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2readinodeblock+0xb5/0x110 (fs/ocfs2/suballoc.c:?) downwrite+0xf5/0x180 (?:?) ocfs2writebegin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __markinodedirty+0x758/0x9a0 (?:?) inodetobdi+0x41/0x90 (?:?) balancedirtypagesratelimitedflags+0xf8/0x1d0 (?:?) genericperformwrite+0x252/0x440 (?:?) mntputwriteaccessfile+0x16/0x70 (?:?) fileupdatetimeflags+0xe4/0x200 (?:?) ocfs2filewriteiter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lockacquire+0x184/0x2f0 (?:?) ksyswrite+0xd2/0x170 (?:?) apparmorfilepermission+0xf5/0x310 (?:?) readzero+0x8d/0x140 (?:?) lockisheldtype+0x8f/0x100 (?:?)(CVE-2026-63796)

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

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, before querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpageinfo (which typically manifests as a host #PF because the lpageinfo is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot.

When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage.

But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds.

BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmustresstest Not tainted 7.1.0-rc1-48ce1e26eace-x86pirtoirrcomments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvmmmumaxmappinglevel+0x79/0x2b0 [kvm] Call Trace: <TASK> kvmmmurecoverhugepages+0x21b/0x320 [kvm] kvmsetmemslot+0x1ee/0x590 [kvm] kvmsetmemoryregion.part.0+0x3a1/0x4d0 [kvm] kvmvmioctl+0x9bf/0x15d0 [kvm] __x64sysioctl+0x8a/0xd0 dosyscall64+0xb7/0xbb0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK>

Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVMPAGESPERHPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvmmmumaxmapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.(CVE-2026-63807)

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

keys: Pin requestkeyauth payload in instantiate paths

A: requestkey() B: KEYCTLINSTANTIATE_IOV ================ =========================

create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF

helper completed detach and free rka destroy auth key wake up use rka->target_key USE-AFTER-FREE

Give requestkeyauth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy.

jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.

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

USB: serial: mct_u232: fix memory corruption with small endpoint

The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint.

Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63898)

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.(CVE-2026-63940)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevfcleanrx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevfaddrxfrag() on the freed skb, dereferencing skbshinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scandropcontinueloops.py + semgrep dropcontinueinloop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfreeskb, then read skbshinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevfuaftest_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

vsock/vmci: fix UAF when peer resets connection during handshake

vmcitransportrecvconnectingserver() returned err = 0 for a peer RST in its default switch arm:

err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;

That made vmcitransportrecvlisten() skip vsockremovepending(), leaving the pending socket on the listener's pendinglinks with skstate = TCPCLOSE while destroy: still dropped the explicit reference taken before scheduledelayedwork().

One second later vsockpendingwork() observed ispending=true and performed full cleanup: vsockremovepending() then the two trailing sockput(sk) calls -- the first reached refcount 0 and _skfreed the socket, and the second wrote into the freed object:

BUG: KASAN: slab-use-after-free in refcountwarnsaturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsockpendingwork

Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmcitransportrecvlisten() removes pending from pendinglinks synchronously and vsockpendingwork() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it.

The pre-existing skacceptqremoved() gap on the err < 0 path of vmcitransportrecv_listen() that Sashiko also noted is not introduced or changed by this patch.

Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.(CVE-2026-64115)

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)(CVE-2026-64178)

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

crypto: qat - protect service table iterations with service_lock

The servicetable list is protected by servicelock when entries are added or removed (in adfserviceadd() and adfserviceremove()), but several functions iterate over the list without holding this lock.

A concurrent adfserviceregister() or adfserviceunregister() call could modify the list during traversal, leading to list corruption or a use-after-free.

Fix this by holding servicelock across all listforeachentry() iterations of servicetable in adfdevinit(), adfdevstart(), adfdevstop(), adfdevshutdown(), adfdevrestartingnotify(), adfdevrestartednotify(), and adferror_notifier().

The lock ordering is safe: callers of the static helpers (adfdevup() and adfdevdown()) acquire statelock before servicelock, and no eventhld callback or servicelock holder ever acquires state_lock in the reverse order.(CVE-2026-64305)

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

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmetexecutediscgetlogpage() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmetcopytosgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:

u64 offset      = nvmet_get_log_page_offset(req->cmd);  /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req->cmd);     /* 32-bit host */
...
if (offset & 0x3) { ... }                               /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);

The Discovery controller is unauthenticated -- nvmethostallowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloclen reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panicon_oops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmetcopytosgl(req, 0, buffer + ATTACKEROFFSET, ...)" is unique to nvmetexecutediscgetlog_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmetexecutegetlogchanged_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.(CVE-2026-64320)

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

udf: validate sparing table length as an entry count, not a byte count

udfloadsparable_map() accepts a sparing table when

sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:

for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
    struct sparingEntry *entry = &st->mapEntry[i];
    ... entry->origLocation ...
}

in udfgetpblockspar15() and udfrelocateblocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udfgetpblockspar15(); udfrelocateblocks() additionally feeds the same length to udfupdatetag(), whose crcitut() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.

Validate reallocationTableLen as the entry count it is, with struct_size().(CVE-2026-64322)

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

proc: protect ptracemayaccess() with execupdatelock (FD links)

procpidgetlink() and procpid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways.

To fix it, pass the task to the ->procgetlink() handler, and instead of procfdaccessallowed(), introduce a new helper callprocgetlink() that looks up and locks the task, does the access check, and calls ->procgetlink().(CVE-2026-64375)

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

smb: client: mask server-provided mode to 07777 in modefromsid

When modefromsid is active, parsedacl() applies the server-provided subauth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)

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

smb: client: harden POSIX SID length parsing

posixinfosid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)

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

fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns

In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time:

BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount

Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array:

1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow.
2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.

Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.

This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").(CVE-2026-64432)

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

nvmet-tcp: check INITFAILED before nvmetreq_uninit in digest error path

In nvmettcptryrecvddgst(), when a data digest mismatch is detected, nvmetrequninit() is called unconditionally. However, if the command arrived via the nvmettcphandlereqfailure() path, nvmetreqinit() had returned false and percpureftrygetlive() was never executed. The unconditional percpurefput() inside nvmetrequninit() then causes a refcount underflow, leading to a WARNING in percpurefswitchtoatomicrcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock.

Check cmd->flags & NVMETTCPFINITFAILED before calling nvmetrequninit(), matching the existing pattern in nvmettcpexecute_request().(CVE-2026-64534)

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

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

eircreateadvdata() builds the advertising data into a fixed-size buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags" AD structure (LEADNOBREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits:

memcpy(ptr, adv->adv_data, adv->adv_data_len);

tlvdatamaxlen() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with advdatalen up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + advdata_len bytes into the size-byte buffer:

BUG: KASAN: stack-out-of-bounds in eircreateadvdata (net/bluetooth/eir.c:301) Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65 Workqueue: hci0 hcicmdsyncwork __asanmemcpy (mm/kasan/shadow.c:106) eircreateadvdata (net/bluetooth/eir.c:301) hciupdateadvdatasync (net/bluetooth/hcisync.c:1310) hcischeduleadvinstancesync (net/bluetooth/hcisync.c:1817) hcicmdsyncwork (net/bluetooth/hcisync.c:332) This frame has 1 object: [32, 64) 'cp'

The "Flags" structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data.

Reachable by a local user with CAPNETADMIN owning an LE-only controller on the legacy advertising path.(CVE-2026-64539)

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

Bluetooth: L2CAP: Fix use-after-free in l2capsocknewconnectioncb()

l2capsocknewconnectioncb() returned l2cappi(sk)->chan after releasesock(parent). Once the parent lock is dropped the newly enqueued child socket sk is reachable via the accept queue, so another task can accept and free it before the callback dereferences sk, resulting in a use-after-free.

Rework the ->newconnection() op so the core, rather than the callback, owns the child channel's lifetime. The op now receives a pre-allocated newchan and returns an errno instead of allocating and returning a channel. l2capnewconnection() allocates the child channel and links it into the conn list via _l2capchanadd() before invoking the callback, so the conn-list reference keeps the channel alive once releasesock(parent) exposes the socket to other tasks.

Channel configuration that was duplicated in l2capsockinit() and the various newconnection callbacks is consolidated into l2capchansetdefaults(), which now inherits from the parent channel when one is supplied.(CVE-2026-64557)