The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

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

smb: client: let smbddestroy() call disableworksync(&info->postsendcreditswork)

In smbddestroy() we may destroy the memory so we better wait until postsendcreditswork is no longer pending and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxeverbs.c:1032 rxepostrecv+0x1ee/0x480 [rdmarxe] ... [ 5305.686979] [ T138] smbdpostrecv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srsoaliasreturn_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasancheckwrite+0x14/0x30 [ 5305.687185] [ T138] ? __pfxsmbdpostrecv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? pfxrawspinlockirqsave+0x10/0x10 [ 5305.687356] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? rawspinunlockirqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? getreceivebuffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbdpostsendcredits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfxsmbdpostsendcredits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? pfxrawspinlockirq+0x10/0x10 [ 5305.687875] [ T138] ? queuedelayedworkon+0x8e/0xa0 [ 5305.687889] [ T138] processonework+0x629/0xf80 [ 5305.687908] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? _kasancheckwrite+0x14/0x30 [ 5305.687933] [ T138] workerthread+0x87f/0x1570 ...

It means rxepostrecv was called after rdmadestroyqp(). This happened because putreceivebuffer() was triggered by ibdrainqp() and called: queuework(info->workqueue, &info->postsendcreditswork);(CVE-2025-39932)

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

MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits

Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASMiLAmostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASMiLAmostly (and now UASMiLA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the _readmostly section.

This corruption was observed because the variable _cpuprimarythreadmask was corrupted, causing a hang very early during boot.

This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insnlamcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)

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

riscv: Sanitize syscall table indexing under speculation

The syscall number is a user-controlled value used to index into the syscall table. Use arrayindexnospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.(CVE-2025-71203)

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

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the no_hw_access flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smp_mb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)

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

btrfs: reject new transactions if the fs is fully read-only

[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:

BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:findfreeextentupdateloop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:findfreeextent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfsreserveextent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfsalloctreeblock+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfsforcecowblock+0x578/0x2410 fs/btrfs/ctree.c:517 btrfscowblock+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfssearchslot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfstruncateinodeitems+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfsevict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentrykill+0x209/0x660 fs/dcache.c:670 finishdput+0xc9/0x480 fs/dcache.c:879 shrinkdcacheforumount+0xa0/0x170 fs/dcache.c:1661 genericshutdownsuper+0x67/0x2c0 fs/super.c:621 killanonsuper+0x3b/0x70 fs/super.c:1289 btrfskillsuper+0x41/0x50 fs/btrfs/super.c:2127 deactivatelockedsuper+0xbc/0x130 fs/super.c:474 cleanupmnt+0x425/0x4c0 fs/namespace.c:1318 taskworkrun+0x1d4/0x260 kernel/taskwork.c:233 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0x694/0x22f0 kernel/exit.c:971 dogroup_exit+0x21c/0x2d0 kernel/exit.c:1112 __dosysexit_group kernel/exit.c:1123 [inline] __sesysexit_group kernel/exit.c:1121 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1121 x64syscall+0x2210/0x2210 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe8/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>

Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.

But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.

[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.

However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.

[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.(CVE-2026-23214)

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

nvme-fc: release admin tagset if init fails

nvme_fabrics creates an NVMe/FC controller in following path:

nvmf_dev_write()
  -> nvmf_create_ctrl()
    -> nvme_fc_create_ctrl()
      -> nvme_fc_init_ctrl()

nvmefcinitctrl() allocates the admin blk-mq resources right after nvmeaddctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the failctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admintagset in the failctrl path and call nvmeremoveadmintagset() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)

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

netfilter: nfconntrackexpect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nfconntrackexpect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.(CVE-2026-31414)

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

ksmbd: fix OOB write in QUERY_INFO for compound requests

When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.(CVE-2026-31432)

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

dmaengine: idxd: Fix leaking event log memory

During the device remove process, the device is reset, causing the configuration registers to go back to their default state, which is zero. As the driver is checking if the event log support was enabled before deallocating, it will fail if a reset happened before.

Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough.(CVE-2026-31440)

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

dmaengine: idxd: Fix crash when the event log is disabled

If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.

Also, only try to free the event log if it was properly allocated.(CVE-2026-31443)

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

xfs: avoid dereferencing log items after push callbacks

After xfsaildpushitem() calls ioppush(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after ioppush() returns.

Fix this by capturing the log item type, flags, and LSN before calling xfsaildpushitem(), and introducing a new xfsailpush_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)

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

ipv4: nexthop: allocate skb dynamically in rtmgetnexthop()

When querying a nexthop object via RTMGETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSGGOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.

This results in the following warning splat:

WARNING: net/ipv4/nexthop.c:3395 at rtmgetnexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtmgetnexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlinkrcvmsg (net/core/rtnetlink.c:6989) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __syssendmsg (net/socket.c:2671) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Fix this by allocating the size dynamically using nhnlmsgsize() and using nlmsgnew(), this is consistent with nexthopnotify() behavior. In addition, adjust nhnlmsgsizegrp() so it calculates the size needed based on flags passed. While at it, also add the size of NHAFDB for nexthop group size calculation as it was missing too.

This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:

addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)

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

wifi: mac80211: Fix staticbranchdec() underflow for aql_disable.

syzbot reported staticbranchdec() underflow in aqlenablewrite(). [0]

The problem is that aqlenablewrite() does not serialise concurrent write()s to the debugfs.

aqlenablewrite() checks statickeyfalse(&aqldisable.key) and later calls staticbranchinc() or staticbranch_dec(), but the state may change between the two calls.

aql_disable does not need to track inc/dec.

Let's use staticbranchenable() and staticbranchdisable().

WARNING: kernel/jump_label.c:311 at __statickeyslowdeccpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__statickeyslowdeccpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: <TASK> __statickeyslowdeccpuslocked kernel/jump_label.c:297 [inline] __statickeyslowdec kernel/jumplabel.c:321 [inline] statickeyslowdec+0x7c/0xc0 kernel/jumplabel.c:336 aqlenablewrite+0x2b2/0x310 net/mac80211/debugfs.c:343 shortproxywrite+0x133/0x1a0 fs/debugfs/file.c:383 vfswrite+0x2aa/0x1070 fs/readwrite.c:684 ksyspwrite64 fs/readwrite.c:793 [inline] __dosyspwrite64 fs/read_write.c:801 [inline] __sesyspwrite64 fs/read_write.c:798 [inline] __x64syspwrite64+0x1eb/0x250 fs/readwrite.c:798 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xc9/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIGRAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 </TASK>(CVE-2026-31551)

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

nvmet: move async event work off nvmet-wq

For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asyncevent_work)

nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asyncevent_work)

B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() _nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()

C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) _flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N

kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processone_work+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcuread_lock){....}-{1:3}, at: _flushwork+0x62/0x530

Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmet_rdma] Call Trace: _flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.(CVE-2026-31557)

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:

KVM: x86: Use scratch field in MMIO fragment to hold small write values

When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value.

This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, and both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable.

The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data.

================================================================== BUG: KASAN: use-after-free in completeemulatedmmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984

CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x8664 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dumpstack+0xbe/0xfd printaddressdescription.constprop.0+0x19/0x170 __kasanreport.cold+0x6c/0x84 kasanreport+0x3a/0x50 checkmemoryregion+0xfd/0x1f0 memcpy+0x20/0x60 completeemulatedmmio+0x305/0x420 kvmarchvcpuioctlrun+0x63f/0x6d0 kvmvcpuioctl+0x413/0xb20 _sesysioctl+0x111/0x160 dosyscall64+0x30/0x40 entrySYSCALL64afterhwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720

The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================

The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in completeemulatedmmio(), i.e. by overwrite the data value with garbage.

Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---(CVE-2026-31588)

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

tipc: fix bcackers underflow on duplicate GRPACK_MSG

The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.(CVE-2026-31662)

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

xfrm: clear trailing padding in build_polexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuser_polexpire.

The padding bytes after the _u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().(CVE-2026-31664)

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

netfilter: xt_multiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.(CVE-2026-31681)

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

ksmbd: validate owner of durable handle on reconnect

Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.

According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)

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

usb: gadget: fecm: Fix netdevice lifecycle with device_move

The netdevice is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the netdevice survives, resulting in dangling sysfs symlinks:

console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory

Use devicemove() to reparent the netdevice between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling devicemove(NULL) moves the netdevice to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.

To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.(CVE-2026-31725)

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

usb: ulpi: fix double free in ulpiregisterinterface() error path

When deviceregister() fails, ulpiregister() calls put_device() on ulpi->dev.

The device release callback ulpidevrelease() drops the OF node reference and frees ulpi, but the current error path in ulpiregisterinterface() then calls kfree(ulpi) again, causing a double free.

Let putdevice() handle the cleanup through ulpidevrelease() and avoid freeing ulpi again in ulpiregister_interface().(CVE-2026-31759)

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

Bluetooth: hcisync: hcicmdsyncqueue_once() return -EEXIST if exists

hcicmdsyncqueueonce() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.

Change the function to return -EEXIST if queue item already exists.

Modify all callsites to handle that.(CVE-2026-43022)

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

netfilter: ctnetlink: ignore explicit helper on new expectations

Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.

This was uncovered when validating CTAEXPECTCLASS via different helper provided by userspace than the existing master conntrack helper:

BUG: KASAN: slab-out-of-bounds in nfctexpectrelatedreport+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nfctexpectrelatedreport+0x2479/0x27c0 ctnetlinkcreateexpect+0x22b/0x3b0 ctnetlinknewexpect+0x4bd/0x5c0 nfnetlinkrcvmsg+0x67a/0x950 netlinkrcvskb+0x120/0x350

Allowing to read kernel memory bytes off the expectation boundary.

CTAEXPECTHELP_NAME is still used to offer the helper name to userspace via netlink dump.(CVE-2026-43025)

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

netfilter: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpect_init(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNF_NAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.(CVE-2026-43026)

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:

net: ioam6: fix OOB and missing lock

When trace->type.bit6 is set:

if (trace->type.bit6) {
    ...
    queue = skb_get_tx_queue(dev, skb);
    qdisc = rcu_dereference(queue->qdisc);

This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.

While at it, add missing lock around qdiscqstatsqlen_backlog(). The function _ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.(CVE-2026-43083)

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

xfrm: Wait for RCU readers during policy netns exit

xfrmpolicyfini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.

The policybydst tables are published via rcuassignpointer() and are looked up through rcudereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory.

Fix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)

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

ipv4: icmp: fix null-ptr-deref in icmpbuildprobe()

ipv6stub->ipv6devfind() may return ERRPTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIGIPV6=m and not loaded), and passing this error pointer to devhold() will cause a kernel crash with null-ptr-deref.

Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".(CVE-2026-43099)

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

ipv6: ioam: fix potential NULL dereferences in _ioam6filltracedata()

We need to check __in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.(CVE-2026-43101)

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

netfilter: ctnetlink: ensure safe access to master conntrack

Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.

To access exp->master safely:

• Grab the nfconntrackexpectlock, this gets serialized with cleanfrom_lists() which also holds this lock when the master conntrack goes away.

• Hold reference on master conntrack via nfconntrackfind_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.

This patch goes for extending the nfconntrackexpect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.

The add expectation command already holds a reference to the master conntrack from ctnetlinkcreateexpect().

However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nfctexpectiteratenet() calls already grabs the spinlock while iterating over the expectation table, which is correct.

The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL.

For the expectation events, the IPEXPDESTROY event is already delivered under the spinlock, just move the delivery of IPEXPNEW under the spinlock too because the master conntrack event cache is reached through exp->master.

While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.(CVE-2026-43116)

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

dlm: validate length in dlmsearchrsb_tree

The len parameter in dlmdumprsbname() is not validated and comes from network messages. When it exceeds DLMRESNAMEMAXLEN, it can cause out-of-bounds write in dlmsearchrsbtree().

Add length validation to prevent potential buffer overflow.(CVE-2026-43125)

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

ntfs3: fix circular locking dependency in rununpackex

Syzbot reported a circular locking dependency between wnd->rwlock (sbi->used.bitmap) and ni->file.runlock.

The deadlock scenario: 1. ntfsextendmft() takes ni->file.runlock then wnd->rwlock. 2. rununpackex() takes wnd->rwlock then tries to acquire ni->file.runlock inside ntfsrefreshzone().

This creates an AB-BA deadlock.

Fix this by using downreadtrylock() instead of downread() when acquiring runlock in rununpackex(). If the lock is contended, skip ntfsrefreshzone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for runlock while holding wnd->rwlock.(CVE-2026-43127)

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

net: usb: pegasus: enable basic endpoint checking

pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:

• usb_rcvbulkpipe(dev, 1) for RX data
• usb_sndbulkpipe(dev, 2) for TX data
• usb_rcvintpipe(dev, 3) for status interrupts

A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.

Add a pegasususbep enum for endpoint numbers, replacing magic constants throughout. Add usbcheckbulkendpoints() and usbcheckintendpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.

Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")(CVE-2026-43156)

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

md/bitmap: fix GPF in write_page caused by resize race

A General Protection Fault occurs in writepage() during array resize: RIP: 0010:writepage+0x22b/0x3c0 [md_mod]

This is a use-after-free race between bitmapdaemonwork() and __bitmapresize(). The daemon iterates over bitmap->storage.filemap without locking, while the resize path frees that storage via mdbitmapfileunmap(). quiesce() does not stop the md thread, allowing concurrent access to freed pages.

Fix by holding mddev->bitmap_info.mutex during the bitmap update.(CVE-2026-43163)

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

net: usb: kaweth: remove TX queue manipulation in kawethsetrx_mode

kawethsetrxmode(), the ndosetrxmode callback, calls netifstopqueue() and netifwakequeue(). These are TX queue flow control functions unrelated to RX multicast configuration.

The premature netifwakequeue() can re-enable TX while txurb is still in-flight, leading to a double usbsubmit_urb() on the same URB:

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); }

kawethsetrxmode() { netifstopqueue(); netifwake_queue(); // wakes TX queue before URB is done }

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); // URB submitted while active }

This triggers the WARN in usbsubmiturb():

"URB submitted while active"

This is a similar class of bug fixed in rtl8150 by

• commit 958baf5eaee3 ("net: usb: Remove disruptive netifwakequeue in rtl8150setmulticast").

Also kawethsetrxmode() is already functionally broken, the real setrxmode action is performed by kawethasyncsetrxmode(), which in turn is not a no-op only at ndoopen() time.(CVE-2026-43180)

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

ipv6: ioam: fix heap buffer overflow in _ioam6filltracedata()

On the receive path, _ioam6filltracedata() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skbsharedinfo), which corrupts adjacent heap memory and leads to a kernel panic.

Add a shared helper ioam6tracecompute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:

• in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation;
• in exthdrs.c (receive path, ipv6hopioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.

Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6MASKSHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).(CVE-2026-43186)

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

net: consume xmit errors of GSO frames

udpgrofrglist.sh and udpgrobench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min.

These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on.

Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's sndnxt is at sequence number N [1], but the receiver claims to have received (rcvnxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]).

In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4MSS:N-3MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCPACKUNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck.

The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this:

| GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

 x    ok    ok    <ok>|  ok    ok    ok   <x>
                      \\
           snd_nxt

"x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent.

So why did the sender not advance sndnxt even tho it clearly did send up to seg 8? tcpwrite_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above).

Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely.

We have multiple ways to fix this.

1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great.

2) fix the damn return codes We only talk about NETDEVTXOK and NETDEVTXBUSY in the documentation, so maybe we should make the return code from ndostartxmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer.

3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ipqueuexmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss?

4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQFCAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?

Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).(CVE-2026-43194)

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

netconsole: avoid OOB reads, msg is not nul-terminated

msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printksharedpbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see:

printk: console [netcon_ext0] enabled
BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240
Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594

CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9
Call Trace:
 kasan_report+0xe4/0x120
 string+0x1f7/0x240
 vsnprintf+0x655/0xba0
 scnprintf+0xba/0x120
 netconsole_write+0x3fe/0xa10
 nbcon_emit_next_record+0x46e/0x860
 nbcon_kthread_func+0x623/0x750

Allocated by task 1:
 nbcon_alloc+0x1ea/0x450
 register_console+0x26b/0xe10
 init_netconsole+0xbb0/0xda0

The buggy address belongs to the object at ffff88813b6d4000
            which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 0 bytes to the right of
            allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)(CVE-2026-43197)

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

iommu/amd: serialize sequence allocation under concurrent TLB invalidations

With concurrent TLB invalidations, completion wait randomly gets timed out because cmdsemval was incremented outside the IOMMU spinlock, allowing CMDCOMPLWAIT commands to be queued out of sequence and breaking the ordering assumption in waitonsem(). Move the cmdsemval increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return.(CVE-2026-43220)

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

smb: client: prevent races in ->query_interfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating ifacelastupdate under iface_lock.(CVE-2026-43239)

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

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.

BUG: unable to handle page fault for address: ffff97793ff47000
RIP: ima_restore_measurement_list+0xdc/0x45a
#PF: error_code(0x0000) – not-present page

Other architectures already validate the range with pageisram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.

Without carrying the measurement list across kexec, the attestation would fail.(CVE-2026-43240)

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

ext4: move ext4percpuparaminit() before ext4mb_init()

When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the DOUBLE_CHECK macro defined, the following panic is triggered:

================================================================== EXT4-fs error (device vdc): ext4validateblockbitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpucounteraddbatch+0x13/0xa0 Call Trace: <TASK> ext4markgroupbitmapcorrupted+0xcb/0xe0 ext4validateblockbitmap+0x2a1/0x2f0 ext4readblockbitmap+0x33/0x50 mbgroupbbbitmapalloc+0x33/0x80 ext4mbaddgroupinfo+0x190/0x250 ext4mbinitbackend+0x87/0x290 ext4mbinit+0x456/0x640 __ext4fillsuper+0x1072/0x1680 ext4_fillsuper+0xd3/0x280 gettreebdevflags+0x132/0x1d0 vfsgettree+0x29/0xd0 vfscmdcreate+0x59/0xe0 __dosysfsconfig+0x4f6/0x6b0 dosyscall64+0x50/0x1f0

entrySYSCALL64afterhwframe+0x76/0x7e

This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test

With DOUBLECHECK defined, mbgroupbbbitmapalloc() reads and validates the block bitmap. When the validation fails, ext4markgroupbitmapcorrupted() attempts to update sbi->sfreeclusterscounter. However, this percpucounter has not been initialized yet at this point, which leads to the panic described above.

Fix this by moving the execution of ext4percpuparaminit() to occur before ext4mb_init(), ensuring the per-CPU counters are initialized before they are used.(CVE-2026-43288)

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

md raid: fix hang when stopping arrays with metadata through dm-raid

When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.

This occurs when:

• A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)

• The top-level RAID device is then removed

Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.

Fix:

• Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O

• Still allow write-intent bitmap flushing when called from dm-raid suspend context

This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.

This second patch uses mdisrdwr() to distinguish between suspend and destructor paths as elaborated on above.(CVE-2026-43309)

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

spi: spidev: fix lock inversion between spilock and buflock

The spidev driver previously used two mutexes, spilock and buflock, but acquired them in different orders depending on the code path:

write()/read(): buflock -> spilock ioctl(): spilock -> buflock

This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:

WARNING: possible circular locking dependency detected spidevioctl() -> mutexlock(&spidev->buflock) spidevsyncwrite() -> mutexlock(&spidev->spi_lock) *** DEADLOCK ***

The issue is reproducible with a simple userspace program that performs write() and SPIIOCWRMAXSPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.

Fix this by simplifying the locking model and removing the lock inversion entirely. spidevsync() no longer performs any locking, and all callers serialize access using spilock.

buflock is removed since its functionality is fully covered by spilock, eliminating the possibility of lock ordering issues.

This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.(CVE-2026-43319)

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

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smpcmdpairingreq() currently builds the pairing response from the initiator authreq before enforcing the local BTSECURITYHIGH requirement. If the initiator omits SMPAUTHMITM, the response can also omit it even though the local side still requires MITM.

tkrequest() then sees an auth value without SMPAUTHMITM and may select JUSTCFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMPAUTHMITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.(CVE-2026-43334)

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

smb: client: require a full NFS mode SID before reading mode bits

parsedacl() treats an ACE SID matching sidunixNFSmode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.

That assumes the ACE carries three subauthorities, but comparesids() only compares min(a, b) subauthorities. A malicious server can return an ACE with numsubauth = 2 and subauth[] = {88, 3}, which still matches sidunixNFSmode and then drives the sub_auth[2] read four bytes past the end of the ACE.

Require numsubauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing comparesids() semantics for the rest of cifsacl.(CVE-2026-43350)

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

io_uring/kbuf: check if target buffer list is still legacy on recycle

There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks.(CVE-2026-43366)

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

libceph: prevent potential out-of-bounds reads in processmessageheader()

If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in processmessageheader().

Perform an explicit bounds check before decoding the message header.(CVE-2026-43406)

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

e1000/e1000e: Fix leak in DMA error cleanup

If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb.

Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dmaerror is reached. Decrementing count before the while loop in dmaerror causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak.

In these commits, a faulty while condition caused an infinite loop in dmaerror: Commit 03b1320dfcee ("e1000e: remove use of skbdmamap from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skbdma_map from e1000 driver")

Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *txmap()") fixed the infinite loop, but introduced the off-by-one error.

This issue may still exist in the igbvf driver, but I did not address it in this patch.(CVE-2026-43445)

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

net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery

In case of a TX error CQE, a recovery flow is triggered, mlx5eresettxqsqccpc() resets dmafifocc to 0 but not dmafifopc, desyncing the DMA FIFO producer and consumer.

After recovery, the producer pushes new DMA entries at the old dmafifopc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.

The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dmafifocc is already equal to dmafifopc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched.

Remove the 'dmafifocc = 0' reset.

This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommudmaunmappage+0x79/0x90 Modules linked in: mlx5vdpa vringh vdpa bonding mlx5ib mlx5vfiopci ipip mlx5fwctl tunnel4 mlx5core ibipoib geneve ip6gre ipgre gre nftables ip6tunnel rdmaucm ibuverbs ibumad vfiopci vfiopcicore actmirred actskbedit actvlan vhostnet vhost tap ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle clsmatchall nfnetlinkcttimeout actgact clsflower schingress vhostiotlb iptableraw tunnel6 vfioiommutype1 vfio openvswitch nsh rpcsecgsskrb5 authrpcgss oidregistry xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter overlay zram zsmalloc rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm ibcore fuse [last unloaded: nftables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5forupstreammindebug202412302133 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommudmaunmap_page+0x79/0x90 ? reportbug+0x16d/0x180 ? handlebug+0x4f/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 ? iommudmaunmappage+0x2e/0x90 dmaunmappageattrs+0x10d/0x1b0 mlx5etxwidmaunmap+0xbe/0x120 [mlx5core] mlx5epolltxcq+0x16d/0x690 [mlx5core] mlx5enapipoll+0x8b/0xac0 [mlx5core] _napipoll+0x24/0x190 netrxaction+0x32a/0x3b0 ? mlx5eqcompint+0x7e/0x270 [mlx5core] ? notifiercallchain+0x35/0xa0 handlesoftirqs+0xc9/0x270 irqexitrcu+0x71/0xd0 commoninterrupt+0x7f/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40(CVE-2026-43466)

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

net/mlx5: Fix deadlock between devlink lock and esw->wq

esw->workqueue executes eswfunctionschangedeventhandler -> eswvfschangedevent_handler and acquires the devlink lock.

.eswitchmodeset (acquires devlink lock in devlinknlpredoit) -> mlx5devlinkeswitchmodeset -> mlx5eswitchdisablelocked -> mlx5eswitcheventhandlerunregister -> flushworkqueue deadlocks when eswvfschangedevent_handler executes.

Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5eswitcheventhandlerunregister. - the counter is read and passed to the ephemeral mlx5hostwork struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5eswitchcleanup does the final draining before destroying the wq.

No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vportchangehandler work items, but that's ok since those are disabled elsewhere: - mlx5eswitchdisablelocked disables the vport eq notifier. - mlx5eswvportdisable disarms the HW EQ notification and marks vport->enabled under statelock to false to prevent pending vport handler from doing anything. - mlx5eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.(CVE-2026-43468)

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

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockstatechangecb()

Add the same NULL guard already present in l2capsockresumecb() and l2capsockreadycb().(CVE-2026-45834)

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

netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation

Ulrich reports a regression with nfqueue:

If an application did not set the 'FGSO' capability flag and a gso packet with an unconfirmed nfconn entry is received all packets are now dropped instead of queued, because the check happens after skbgsosegment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skbclone happening via skbgso_segment().

Move the check so that its peformed vs. the aggregated packet.

Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.

For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.

While at it, simplify nfctdrop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.

This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.

Next patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)

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

gfs2: Fix slab-use-after-free in qd_put

Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2qdshrink_scan) tried to access already-freed objects on the LRU list.

Fix this by removing qd objects from the LRU list before freeing them in qd_put().

Initial fix from Deepanshu Kartikey <(CVE-2026-45861)

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

bpf: Fix bpfxdpstore_bytes proto for read-only arg

While making some maps in Cilium read-only from the BPF side, we noticed that the bpfxdpstore_bytes proto is incorrect. In particular, the verifier was throwing the following error:

; ret = ctxstorebytes(ctx, l3off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpfxdpstorebytes#190 write into map forbidden, value_size=6 off=0 size=4

nat comes from a BPFFRDONLYPROG map, so R3 is a PTRTOMAPVALUE. The verifier checks the helper's memory access to R3 in checkmemsizereg, as it reaches ARGCONSTSIZE argument. The third argument has expected type ARGPTRTOUNINITMEM, which includes the MEMWRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails.

Conversely, ARGPTRTOUNINITMEM can also lead to the helper reading from uninitialized memory.

This patch simply fixes the expected argument type to match that of bpfskbstore_bytes.(CVE-2026-45886)

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

usb: cdns3: fix role switching during resume

If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.

The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.

So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksys_write+0x70/0x108 _arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---(CVE-2026-45911)

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

gfs2: fix memory leaks in gfs2fillsuper error path

Fix two memory leaks in the gfs2fillsuper() error handling path when transitioning a filesystem to read-write mode fails.

First leak: kthread objects (threadstruct, taskstruct, etc.) When gfs2freezelockshared() fails after initthreads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the failpernode label doesn't call gfs2destroythreads().

Second leak: quota bitmap buffer (8192 bytes) When gfs2makefsrw() fails after gfs2quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.

The fix moves thread cleanup to the failpernode label to handle all error paths uniformly. gfs2destroythreads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2makefs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.

Thread leak backtrace (gfs2freezelockshared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copyprocess+0x3a1/0x4670 kernel/fork.c:2422 kernelclone+0xf3/0x6e0 kernel/fork.c:2779 kthreadcreateonnode+0x100/0x150 kernel/kthread.c:478 initthreads+0xab/0x350 fs/gfs2/opsfstype.c:611 gfs2fillsuper+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265

Quota leak backtrace (gfs2makefsrw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2quotainit+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2makefsrw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2fillsuper+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)

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

ACPICA: Fix NULL pointer dereference in acpievaddressspacedispatch()

Cover a missed execution path with a new check.(CVE-2026-45982)

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

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in gfs2iomapbegin() via releasemetapath() while iomap->inlinedata still points to dibh->bdata. This causes a use-after-free when iomapwriteendinline() later attempts to write to the inline data area.

The bug sequence: 1. gfs2iomapbegin() calls gfs2metainodebuffer() to read inode metadata into dibh 2. Sets iomap->inlinedata = dibh->bdata + sizeof(struct gfs2dinode) 3. Calls releasemetapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomapwriteendinline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount with getbh() in gfs2iomapbegin(). The buffer is then properly released in gfs2iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.

agruenba: Take buffer head reference in gfs2iomapbegin() to avoid leaks in gfs2iomapget() and gfs2iomapalloc().

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

erofs: fix unsigned underflow in zerofslz4handleoverlap()

Some crafted images can have illegal (!partialdecoding && mllen < mplen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressedpages array.

However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path.

Let's add an additional check to fix this for backporting.

Reproducible image (base64-encoded gzipped blob):

H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA=

$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)

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

drm/nouveau: fix u32 overflow in pushbuf reloc bounds check

nouveaugempushbufrelocapply() validates each relocation with

if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)

but relocbooffset is __u32 (uapi/drm/nouveaudrm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the sizet bo size.

Cast to u64 so the addition happens in 64-bit arithmetic.

Add Fixes: tag. - Danilo

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

KVM: SVM: Add missing save/restore handling of LBR MSRs

MSRIA32DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVMGETMSRINDEXLIST, and LBR MSRs cannot be set with KVMSETMSRS. So save/restore is completely broken.

Fix it by adding the MSRs to msrstosavebase, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svmcopyvmrunstate().

Note, for VMX, this also fixes a flaw where MSRIA32DEBUGCTLMSR isn't reported as an MSR to save/restore.

Note #2, over-reporting MSRIA32LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvmdomsr_access() will morph the unsupported userspace write into a nop).

sean: guard with lbrv checks, massage changelog

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

ipmi:ssif: Clean up kthread on errors

If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped.

So make sure the kthread is stopped on an error condition if it is running.(CVE-2026-46044)

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

md/raid5: fix soft lockup in retryalignedread()

When retryalignedread() encounters an overlapped stripe, it releases the stripe via raid5releasestripe() which puts it on the lockless releasedstripes llist. In the next raid5d loop iteration, releasestripelist() drains the stripe onto handlelist (since STRIPEHANDLE is set by the original IO), but retryalignedread() runs before handleactivestripes() and removes the stripe from handlelist via findgetstripe() -> listdelinit(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup.

Fix this by using _releasestripe() with tempinactivelist instead of raid5releasestripe() in the failure path, so the stripe does not go through the releasedstripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handlestripe().(CVE-2026-46051)

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

ceph: only d_add() negative dentries when they are unhashed

Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash.

In the current VFS that is not safe. d_add() goes through __d_add() to __drehash(), which unconditionally reinserts dentry->dhash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, _dlookup() can spin forever in the hlistbl walk, typically looping only on the dname.hash mismatch check and eventually triggering RCU stall reports like this one:

rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__dlookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookupfast+0x9f/0x100 walkcomponent+0x1f/0x150 linkpathwalk+0x20e/0x3d0 pathlookupat+0x68/0x180 filenamelookup+0xdc/0x1e0 vfsstatx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __dosysnewfstatat+0x24/0x60 dosyscall64+0x6a/0x230 entrySYSCALL64afterhwframe+0x76/0x7e

This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed":

• cephfinishlookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL)

• cephlookup(): local ENOENT fast path for a complete directory with shared caps -> dadd(dentry, NULL)

Both paths can therefore re-add an already-hashed negative dentry.

Ceph already uses the correct pattern elsewhere: cephfilltrace() only calls dadd(dn, NULL) for a negative null-dentry reply when dunhashed(dn) is true.

Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is.

This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)

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

KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1

Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nestedsvml2tlbflush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1.

The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted.

Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well.

sean: rewrite changelog and comment, tag for stable, remove defunct stubs

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

erofs: fix the out-of-bounds nameoff handling for trailing dirents

Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs.

If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block.

nameoff0 should also be verified to be a multiple of sizeof(struct erofs_dirent) as well [1].

[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com(CVE-2026-46078)

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

KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0

INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0.

sean: tag for stable@

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

mm/vmalloc: take vmappurgelock in shrinker

decayvapool_node() can be invoked concurrently from two paths: __purgevmaparealazy() when pools are being purged, and the shrinker via vmapnodeshrinkscan().

However, decayvapool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks.

Protect decayvapoolnode() by taking vmappurge_lock in the shrinker path to ensure serialization with purge users.(CVE-2026-46093)

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

Bluetooth: hcievent: Fix OOB read and infinite loop in hcilecreatebigcompleteevt

hcilecreatebigcompleteevt() iterates over BTBOUND connections for a BIG handle using a while loop, accessing ev->bishandle[i++] on each iteration. However, there is no check that i stays within ev->numbis before the array access.

When a controller sends a LECreateBIGComplete event with fewer bishandle entries than there are BTBOUND connections for that BIG, or with numbis=0, the loop reads beyond the valid bishandle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCICONNHANDLEMAX (0x0EFF), hciconnsethandle() rejects them and the connection remains in BTBOUND state. The same connection is then found again by hciconnhashlookupbigstate(), creating an infinite loop with hcidev_lock held.

Fix this by terminating the BIG if in case not all BIS could be setup properly.(CVE-2026-46138)

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

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdevput() must happen after the RCU grace period. So, either in an RCU call or after the synchronizenet(). The rtnldeletelink() must happen under RTNL and so can't be executed in RCU context. Calling synchronizenet() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdevput() in RCU call is the right solution here.

However, when the device is deleted, rtnlunlock() will call netdevruntodo() and block until all the references are gone. In the current code this means that we never reach the callrcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcucall() before the rtnlunlock(), so the scheduled RCU callback will be executed when synchronizenet() is called from the rtnlunlock()->netdevruntodo() while the RTNL itself is already released.(CVE-2026-46165)

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

riscv: kvm: fix vector context allocation leak

When the second kzalloc (hostcontext.vector.datap) fails in kvmriscvvcpuallocvectorcontext, the first allocation (guest_context.vector.datap) is leaked. Free it before returning.(CVE-2026-46171)

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

x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache

Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.(CVE-2026-46174)

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

RDMA/mlx4: Fix resource leak on error in mlx4ibcreate_srq()

Sashiko points out that mlx4srqalloc() was not undone during error unwind, add the missing call to mlx4srqfree().(CVE-2026-46178)

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

mtd: spi-nor: debugfs: fix out-of-bounds read in spinorparams_show()

Sashiko noticed an out-of-bounds read [1].

In spinorparamsshow(), the snorfnames array is passed to spinorprintflags() using sizeof(snorfnames).

Since snorfnames is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended.

Inside spinorprintflags(), the 'nameslen' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count.

Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.(CVE-2026-46190)

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

netfilter: nftinner: Fix IPv6 innerthoff desync

In nftinnerparsel2l3(), when processing inner IPv6 packets, ipv6findhdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between innerthoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTOTCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2.

For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6findhdr()'s result. Removing the incorrect overwrite ensures that ipv6findhdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.(CVE-2026-46244)

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

tap: free page on error paths in tapgetuser_xdp()

tapgetuserxdp() rejects a frame shorter than ETHHLEN with -EINVAL, and returns -ENOMEM when buildskb() fails. Both paths jump to the err label without freeing the page that vhostnetbuildxdp() allocated for the frame. tapsendmsg() discards the per-buffer return value and always returns 0, so vhosttx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk.

Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tunxdpone().(CVE-2026-46320)

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

tun: free page on short-frame rejection in tunxdpone()

tunxdpone() returns -EINVAL on a frame shorter than ETHHLEN without freeing the page that vhostnetbuildxdp() allocated for it. tunsendmsg() discards that -EINVAL and still returns totallen, so vhosttxbatch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk.

A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.(CVE-2026-46321)

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

tun: free page on buildskb failure in tunxdp_one()

When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the putpage() the other error exits of tunxdp_one() already perform.(CVE-2026-46322)

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

net: gro: don't merge zcopy skbs

skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAG_REFS flag.

When SKBFLMANAGEDFRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.(CVE-2026-46323)

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

Revert "net/smc: Introduce TCP ULP support"

This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.

As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying struct file, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability.

Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.(CVE-2026-46330)