OESA-2026-2869

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:

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:

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:

arm64: io: Extract user memory type in ioremap_prot()

The only caller of ioremapprot() outside of the generic ioremap() implementation is genericaccessphys(), which passes a 'pgprott' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprott' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremapprot() which faults when accessed from the kernel on systems with PAN:

| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpyfromio+0x80/0xf8 | genericaccess_phys+0x20c/0x2b8 | __accessremotevm+0x46c/0x5b8 | access_remotevm+0x18/0x30 | environread+0x238/0x3e8 | vfsread+0xe4/0x2b0 | ksysread+0xcc/0x178 | __arm64sysread+0x4c/0x68

Extract only the memory type from the user 'pgprott' in ioremapprot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps _ioremapprot().(CVE-2026-23346)

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

ice: change XDP RxQ fragsize from DMA write length to xdp.framesz

The only user of fragsize field in XDP RxQ info is bpfxdpfragsincrease_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.

This allows to trigger kernel panic, when using XDPADJUSTTAILGROWMULTIBUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSKUMEM__MAXFRAMESIZE * 100.

Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.

Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.(CVE-2026-23377)

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:

mm/hugememory: fix folio isn't locked in softleafto_folio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0                                             CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries _splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In _splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleafto_page().

[(CVE-2026-31466)

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

net: openvswitch: Avoid releasing netdev before teardown completes

The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdevdestroy() callback can proceed immediately to the callrcu() invocation if the IFFOVSDATAPATH flag is already cleared on the netdev.

The ovsnetdevdetachdev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdevdestroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:

[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el102.x8664+rt #1 PREEMPTRT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:devsetpromiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393961] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393975] ? dpdevice_event+0x41/0x80 [openvswitch] [ 998.394009] ? __diebody.cold+0x8/0x12 [ 998.394016] ? dieaddr+0x3c/0x60 [ 998.394027] ? excgeneralprotection+0x16d/0x390 [ 998.394042] ? asmexcgeneralprotection+0x26/0x30 [ 998.394058] ? devsetpromiscuity+0x8d/0xa0 [ 998.394066] ? ovsnetdevdetachdev+0x3a/0x80 [openvswitch] [ 998.394092] dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394102] notifiercallchain+0x5a/0xd0 [ 998.394106] unregisternetdevicemanynotify+0x51b/0xa60 [ 998.394110] rtnldellink+0x169/0x3e0 [ 998.394121] ? rtmutexslowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlinkrcvmsg+0x142/0x3f0 [ 998.394128] ? avchasperm_noaudit+0x69/0xf0 [ 998.394130] ? __pfxrtnetlinkrcvmsg+0x10/0x10 [ 998.394132] netlinkrcvskb+0x50/0x100 [ 998.394138] netlinkunicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __syssendmsg+0x7a/0xd0 [ 998.394160] dosyscall64+0x7f/0x170 [ 998.394162] entrySYSCALL64afterhwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---(CVE-2026-31508)

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:

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NF_STOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.(CVE-2026-31663)

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:

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:

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:

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:

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:

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:

sched/fair: Fix zero_vruntime tracking fix

John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking").

The combination of yield and that commit was specific enough to hypothesize the following scenario:

Suppose we have 2 runnable tasks, both doing yield. Then one will be eligible and one will not be, because the average position must be in between these two entities.

Therefore, the runnable task will be eligible, and be promoted a full slice (all the tasks do is yield after all). This causes it to jump over the other task and now the other task is eligible and current is no longer. So we schedule.

Since we are runnable, there is no {de,en}queue. All we have is the _{en,de}queueentity() from {putprev,setnext}task(). But per the fingered commit, those two no longer move zerovruntime.

All that moves zero_vruntime are tick and full {de,en}queue.

This means, that if the two tasks playing leapfrog can reach the critical speed to reach the overflow point inside one tick's worth of time, we're up a creek.

Additionally, when multiple cgroups are involved, there is no guarantee the tick will in fact hit every cgroup in a timely manner. Statistically speaking it will, but that same statistics does not rule out the possibility of one cgroup not getting a tick for a significant amount of time -- however unlikely.

Therefore, just like with the yield() case, force an update at the end of every slice. This ensures the update is never more than a single slice behind and the whole thing is within 2 lag bounds as per the comment on entity_key().(CVE-2026-43323)

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:

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:

nvme-pci: Fix race bug in nvmepollirqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirq_vector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enable_irq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)

task 2: nvmeresetwork() nvmedevdisable() pdev->msix_enable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at __enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:__enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] __rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] __rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] __dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] __irqexitrcu+0xdc/0x120 ---truncated---(CVE-2026-43448)

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:

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:

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:

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)