The Linux Kernel, the operating system core itself.

Security Fix(es):

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

wifi: rtw88: Use devmkmemdup() in rtwsetsupportedband()

Simplify the code by using device managed memory allocations.

This also fixes a memory leak in rtwregisterhw(). The supported bands were not freed in the error path.

Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89coresetsupportedband to use devm_*").(CVE-2025-71273)

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:

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.(CVE-2026-43109)

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

srcu: Use irq_work to start GP in tiny SRCU

Tiny SRCU's srcugpstartifneeded() directly calls schedule_work(), which acquires the workqueue pool->lock.

This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to:

callsrcu() [holding pilock] srcugpstartifneeded() schedule_work() -> pool->lock

workqueueinit() / createworker() [holding pool->lock] wakeupprocess() -> trytowakeup() -> pilock

Also add irqworksync() to cleanupsrcustruct() to prevent a use-after-free if a queued irq_work fires after cleanup begins.

Tested with rcutorture SRCU-T and no lockdep warnings.

Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irqwork to start processsrcu()"

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

wifi: iwlwifi: fix 22000 series SMEM parsing

If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smemcfg.lmac[2]" is an overrun of the array. Reject such and use IWLFWCHECK instead of WARNON in this function.(CVE-2026-43172)

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

bonding: fix type confusion in bondsetupby_slave()

kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskbexpandhead+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: <TASK> ipgreheader+0xdd/0x540 net/ipv4/ipgre.c:900 devhardheader include/linux/netdevice.h:3439 [inline] packetsnd net/packet/afpacket.c:3028 [inline] packetsendmsg+0x3ae5/0x53c0 net/packet/afpacket.c:3108 socksendmsgnosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 _syssendmsg+0x170/0x220 net/socket.c:2678 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x106/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9

When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bondsetupbyslave() directly copies the slave's headerops to the bond device:

bond_dev->header_ops = slave_dev->header_ops;

This causes a type confusion when devhardheader() is later called on the bond device. Functions like ipgreheader(), ip6greheader(),all use netdevpriv(dev) to access their device-specific private data. When called with the bond device, netdevpriv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes.

Fix this by introducing bondheaderops with wrapper functions that delegate to the active slave's headerops using the slave's own device. This ensures netdevpriv() in the slave's header functions always receives the correct device.

The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting headerops from the slave without considering that these callbacks expect a specific netdevpriv() layout.

The type confusion can be observed by adding a printk in ipgre_header() and running the following commands:

ip link add dummy0 type dummy
ip addr add 10.0.0.1/24 dev dummy0
ip link set dummy0 up
ip link add gre1 type gre local 10.0.0.1
ip link add bond1 type bond mode active-backup
ip link set gre1 master bond1
ip link set gre1 up
ip link set bond1 up
ip addr add fe80::1/64 dev bond1(CVE-2026-43456)

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

ata: libata-scsi: avoid Non-NCQ command starvation

When a non-NCQ command is issued while NCQ commands are being executed, atascsiqcissue() indicates to the SCSI layer that the command issuing should be deferred by returning SCSIMLQUEUEXXXBUSY. This command deferring is correct and as mandated by the ACS specifications since NCQ and non-NCQ commands cannot be mixed.

However, in the case of a host adapter using multiple submission queues, when the target device is under a constant load of NCQ commands, there are no guarantees that requeueing the non-NCQ command will be executed later and it may be deferred again repeatedly as other submission queues can constantly issue NCQ commands from different CPUs ahead of the non-NCQ command. This can lead to very long delays for the execution of non-NCQ commands, and even complete starvation for these commands in the worst case scenario.

Since the block layer and the SCSI layer do not distinguish between queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT implementation must ensure forward progress for non-NCQ commands in the presence of NCQ command traffic. This is similar to what SAS HBAs with a hardware/firmware based SAT implementation do.

Implement such forward progress guarantee by limiting requeueing of non-NCQ commands from atascsiqcissue(): when a non-NCQ command is received and NCQ commands are in-flight, do not force a requeue of the non-NCQ command by returning SCSIMLQUEUEXXXBUSY and instead return 0 to indicate that the command was accepted but hold on to the qc using the new deferredqc field of struct ataport.

This deferred qc will be issued using the work item deferredqcwork running the function atascsideferredqcwork() once all in-flight commands complete, which is checked with the port qcdefer() callback return value indicating that no further delay is necessary. This check is done using the helper function atascsischeduledeferredqc() which is called from atascsiqccomplete(). This thus excludes this mechanism from all internal non-NCQ commands issued by ATA EH.

When a port deferred_qc is non NULL, that is, the port has a command waiting for the device queue to drain, the issuing of all incoming commands (both NCQ and non-NCQ) is deferred using the regular busy mechanism. This simplifies the code and also avoids potential denial of service problems if a user issues too many non-NCQ commands.

Finally, whenever ata EH is scheduled, regardless of the reason, a deferred qc is always requeued so that it can be retried once EH completes. This is done by calling the function atascsirequeuedeferredqc() from ataehset_pending(). This avoids the need for any special processing for the deferred qc in case of NCQ error, link or device reset, or device timeout.(CVE-2026-45855)

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

ext4: drop extent cache when splitting extent fails

When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.(CVE-2026-45899)

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

selinux: fix overlayfs mmap() and mprotect() access checks

The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems.

This patch makes use of the newly created securitymmapbacking_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls.(CVE-2026-46054)

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

mptcp: pm: ADD_ADDR rtx: always decrease sk refcount

When an ADDADDR is retransmitted, the sk is held in skreset_timer(). It should then be released in all cases at the end.

Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sockput() (which will become sockput() in the next commit) to fix this potential leak.

While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely".(CVE-2026-46158)

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

selinux: allow multiple opens of /sys/fs/selinux/policy

Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policyopened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUGONs.(CVE-2026-46302)

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

ip6vti: set netnsimmutable on the fallback device.

john1988 and Noam Rathaus reported that vti6initnet() does not set the netnsimmutable flag on the per-netns fallback tunnel device (ip6vti0).

Other similar tunnel drivers (like ip6tunnel, sit, ip6gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.(CVE-2026-52909)

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

net: skbuff: fix missing zerocopy reference in pskb_carve helpers

pskbcarveinsideheader() and pskbcarveinsidenonlinear() both copy the old skbsharedinfo header into a new buffer via memcpy(), which includes the destructorarg pointer (uarg) for MSGZEROCOPY skbs. Neither function calls netzcopyget() for the new shinfo, creating an unaccounted holder: every skbsharedinfo with destructorarg set will call skbzcopyclear() once when freed, but the corresponding netzcopyget() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubufinfomsgzc while TX skbs still hold live destructorarg pointers.

KASAN reports use-after-free on a freed ubufinfomsgzc:

BUG: KASAN: slab-use-after-free in skbreleasedata+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220

Call Trace: skbreleasedata+0x77b/0x810 kfreeskblistreason+0x13e/0x610 skbreleasedata+0x4cd/0x810 skskbreasondrop+0xf3/0x340 skbqueuepurgereason+0x282/0x440 rdstcpincfree+0x1e/0x30 rds_recvmsg+0x354/0x1780 _sysrecvmsg+0xdf/0x180

Allocated by task 219: msgzerocopyrealloc+0x157/0x7b0 tcpsendmsglocked+0x2892/0x3ba0

Freed by task 219: iprecverror+0x74a/0xb10 tcp_recvmsg+0x475/0x530

The skb consuming the late access still referenced the same uarg via shinfo->destructorarg copied by pskbcarveinsidenonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration.

The fix follows the pattern of pskbexpandhead() which has the same memcpy/cloned structure. For pskbcarveinsideheader(), netzcopyget() is placed after skborphanfrags() succeeds, so the orphan error path needs no cleanup. For pskbcarveinsidenonlinear(), netzcopyget() is placed after all failure points and just before skbreleasedata(), so no error path needs cleanup at all -- matching pskbexpandhead() more closely and avoiding the need for a balancing netzcopyput().(CVE-2026-52943)

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

fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in sendsigio() and sendsigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPEPGID), both functions use readlock(&tasklistlock) to traverse the task list. However, they are frequently called from softirq context: - sendsigio() via inputinjectevent -> killfasync - sendsigurg() via tcpcheckurg -> sksendsigurg (NETRXSOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds readlock(&tasklistlock) in dowait(). 2. CPU 1 (process context) attempts writelock(&tasklistlock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls sendsigurg() and attempts to acquire readlock(&tasklistlock), deadlocking because CPU 1 is waiting.

Since PID hashing and doeachpidtask() traversals are already RCU-protected, the readlock on tasklistlock is no longer strictly required for safe traversal. Fix this by replacing tasklistlock with rcureadlock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.

Lockdep splat:

WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->eventlock --> &fowner->lock --> tasklist_lock

Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklistlock); localirqdisable(); lock(&dev->eventlock); lock(&fowner->lock); <Interrupt> lock(&dev->eventlock);

*** DEADLOCK ***(CVE-2026-52946)

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

smb/client: fix possible infinite loop and oob read in symlink_data()

On 32-bit architectures, the infinite loop is as follows:

len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p

On 32-bit architectures, the out-of-bounds read is as follows:

len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8(CVE-2026-52967)

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

netfilter: nftables: join hook list via splicelist_rcu() in commit phase

Publish new hooks in the list into the basechain/flowtable using splicelistrcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.(CVE-2026-52988)

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

sched/psi: fix race between file release and pressure write

A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfsopenfile, which triggers the uaf reported in [1].

Consider the following scenario involving execution on two separate CPUs:

CPU0 CPU1 ==== ==== vfsrmdir() kernfsioprmdir() cgrouprmdir() cgroupknlocklive() cgroupdestroylocked() cgroupaddrmfiles() cgrouprmfile() kernfsremovebyname() kernfsremovebynamens() vfs_write() _kernfsremove() newsyncwrite() kernfsdrain() kernfsfopwriteiter() kernfsdrainopenfiles() cgroupfilewrite() kernfsreleasefile() pressurewrite() cgroupfilerelease() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroupknunlock() cgroupknlocklive() cgroupget(cgrp) cgroupknunlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv

The cgrouprmdir() is protected by the cgroupmutex, it also safeguards the memory deallocation of of->priv performed within cgroupfilerelease(). However, the operations involving of->priv executed within pressurewrite() are not entirely covered by the protection of cgroupmutex. Consequently, if the code in pressurewrite(), specifically the section handling the ctx variable executes after cgroupfile_release() has completed, a uaf vulnerability involving of->priv is triggered.

Therefore, the issue can be resolved by extending the scope of the cgroupmutex lock within pressurewrite() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroupfilerelease() and pressure_write().

And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point after the live kn lock has been successfully acquired.

In another situation, specifically after entering cgroupknlocklive() but before acquiring cgroupmutex, there exists a different class of race condition:

CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================

kernfsfopwriteiter() kernfsgetactiveof(of) pressurewrite() cgroupknlocklive(memory.pressure) cgrouptryget(cgrp) kernfsbreakactiveprotection(kn) ... blocks on cgroup_mutex

                                      cgroup_pressure_write()
                                      cgroup_kn_lock_live(cgroup.pressure)
                                      cgroup_file_show(memory.pressure, false)
                                        kernfs_show(false)
                                          kernfs_drain_open_files()
                                            cgroup_file_release(of)
                                              kfree(ctx)
                                                of->priv = NULL
                                      cgroup_kn_unlock()

... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference

Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.

Now that the scope of the cgroupmutex has been expanded, the original explicit cgroupget/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.

[1] BUG: KASAN: slab-use-after-free in pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroupfilewrite+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---(CVE-2026-52991)

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

netfilter: nat: use kfree_rcu to release ops

Florian Westphal says:

"Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nfhookops that are used to register the callbacks.

However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.

This code will peek back into the nfhookops that are available at the tail of the pointer-array blob used by the datapath.

The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.

But once that changes the nat ops structures have to be deferred too."

Update nfnatregisterfn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlinkhook.(CVE-2026-53000)

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)

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

Bluetooth: l2cap: Add missing chan lock in l2capecredreconf_rsp

l2capecredreconfrsp() calls l2capchandel() without holding l2capchanlock(). Every other l2capchan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.

Add l2capchanhold() and l2capchanlock() before l2capchandel(), and l2capchanunlock() and l2capchanput() after, matching the pattern used in l2capecredconnrsp() and l2capconn_del().(CVE-2026-53071)

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

Bluetooth: fix locking in hciconnrequestevt() with HCIPROTO_DEFER

When protocol sets HCIPROTODEFER, hciconnrequestevt() calls hciconnectcfm(conn) without hdev->lock. Generally hciconnect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF.

Only SCO and ISO set HCIPROTODEFER and only for defer setup listen, and HCIEVCONNREQUEST is not generated for ISO. In the non-deferred listening socket code paths, hciconnect_cfm(conn) is called with hdev->lock held.

Fix by holding the lock.(CVE-2026-53072)

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

bpf: Fix ld_{abs,ind} failure path analysis in subprogs

Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types.

The code generator in bpfgenldabs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld{abs,ind} failed.

This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.(CVE-2026-53090)

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

md: wake raid456 reshape waiters before suspend

During raid456 reshape, direct IO across the reshape position can sleep in raid5makerequest() waiting for reshape progress while still holding an activeio reference. If userspace then freezes reshape and writes md/suspendlo or md/suspendhi, mddevsuspend() kills active_io and waits for all in-flight IO to drain.

This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes.

raid5preparesuspend() already wakes waitforreshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish.

The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.(CVE-2026-53123)

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

netfilter: require Ethernet MAC header before using eth_hdr()

ip6t_eui64, xt_mac, the bitmap:ip,mac, hash:ip,mac, and hash:mac ipset types, and nf_log_syslog access eth_hdr(skb) after either assuming that the skb is associated with an Ethernet device or checking only that the ETH_HLEN bytes at skb_mac_header(skb) lie between skb->head and skb->data.

Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing eth_hdr(skb).(CVE-2026-53131)

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

vsock/virtio: fix potential unbounded skb queue

virtiotransportincrxpkt() checks vvs->rxbytes + len > vvs->bufalloc.

virtiotransportrecvenqueue() skips coalescing for packets with VIRTIOVSOCKSEQEOM.

If fed with packets with len == 0 and VIRTIOVSOCKSEQEOM, a very large number of packets can be queued because vvs->rxbytes stays at 0.

Fix this by estimating the skb metadata size:

(Number of skbs in the queue) * SKB_TRUESIZE(0)(CVE-2026-53132)

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

netfilter: nft_fib: fix stale stack leak via the OIFNAME register

For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.

The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.

Fix both:

• replace the bare "*dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and

• restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.(CVE-2026-53134)

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

drm/amd/display: Clamp VBIOS HDMI retimer register count to array size

[Why & How] The VBIOS integrated info tables (v111 and v21) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*exthdmiregsettings[9] and dp*exthdmi6greg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe.

Clamp each register count to the destination array size using mint() before the copy loops, in both getintegratedinfov11() and getintegratedinfov21().

(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)(CVE-2026-53136)

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

drm/amd/display: Clamp HDMI HDCP2 rxidlist read to buffer size

[Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rxidlist[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read.

Clamp the read length in modhdcpreadrxidlist() to the size of the rxid_list buffer, matching the approach already used in the DP branch.

(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)

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

thunderbolt: Bound root directory content to block size

_tbpropertyparsedir() does not check that contentoffset + contentlen fits within blocklen for the root directory case. When rootdir->length equals or exceeds blocklen - 2, the entry loop reads past the allocated property block.

Add a bounds check after computing contentoffset and contentlen to reject directories whose content extends past the block.(CVE-2026-53149)

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

inet: frags: fix use-after-free caused by the fqdirpreexit() flush

On netns teardown, fqdirpreexit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inetfragqueueflush(). That helper frees all the skbs queued on the fragment queue but does not set INETFRAGCOMPLETE, and leaves q->fragmentstail and q->lastrunhead pointing at the freed skbs. The queue itself stays in the rhashtable.

fqdirpreexit() first lowers highthresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inetfragfind() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INETFRAGCOMPLETE check and then dereferences the freed fragmentstail. inetfragqueueinsert() reads FRAGCB() and ->len of that pointer and, on the append path, writes ->nextfrag, causing a slab use-after-free. IPv6, nfconntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well.

Reset rbfragments, fragmentstail and lastrunhead in inetfragqueueflush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragmentstail. ipfragreinit() already performed this reset after its own flush, so drop the now duplicate code there.(CVE-2026-53175)

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

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

In drivers/infiniband/ulp/isert/ibisert.c, isertloginrecvdone() computes the login request payload length as wc->bytelen minus ISERHEADERSLEN with no lower bound, and loginreqlen is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISERHEADERSLEN (76) bytes, so the subtraction underflows and loginreq_len becomes negative.

isertrxloginreq() then reads that negative length back into a signed int, takes size = min(rxbuflen, MAXKEYVALUEPAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte sizet. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path.

Reject any login PDU shorter than ISERHEADERSLEN before the subtraction, mirroring the existing early return on a failed work completion, so loginreqlen can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISERRXPAYLOADSIZE, so the difference stays at or below MAXKEYVALUEPAIRS and the existing min() clamps it; only the missing lower bound needs to be added.(CVE-2026-53176)

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

bnxt_en: Fix NULL pointer dereference

PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state.

The .errordetected() callback, bnxtioerrordetected(), disables and synchronizes IRQs via bnxtdisableintsync(), which calls bnxtcpnumtoirqnum() to map completion rings to IRQs using bp->bnapi.

Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer.

Check if bp->bnapi is NULL before disabling and synchronizing IRQs.(CVE-2026-53177)

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

udp: clear skb->dev before running a sockmap verdict

On the UDP receive path skb->dev is repurposed as devscratch (the truesize/state cache set by udpsetdevscratch()), through the union { struct netdevice *dev; unsigned long devscratch; } in sk_buff.

When a UDP socket is in a sockmap, skdataready is skpsockverdictdataready(), which calls udpreadskb() -> recvactor() (skpsockverdictrecv) to run the attached SKSKB verdict program in softirq. If that program calls a socket-lookup helper (bpfsklookuptcp/udp, bpfskclookuptcp), bpfskc_lookup() does:

if (skb->dev)
    caller_net = dev_net(skb->dev);

skb->dev still holds the devscratch value (a non-NULL integer), so devnet() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq:

Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpfskclookup net/core/filter.c:7033 [inline] RIP: 0010:bpfsklookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpfprog4675cb904b7071f8+0x12e/0x14e bpfprogrunpinoncpu+0xc6/0x1f0 skpsockverdictrecv+0x1ba/0x350 udpreadskb+0x31a/0x370 skpsockverdictdataready+0x2e3/0x600 __udpenqueuescheduleskb+0x4c8/0x650 udpv6queuercvoneskb+0x3ec/0x740 udp6unicastrcvskb+0x11d/0x140 ip6protocoldeliverrcu+0x61e/0x950 ip6inputfinish+0xa9/0x150 NFHOOK+0x286/0x2f0 ip6input+0x117/0x220 NFHOOK+0x286/0x2f0 __netifreceiveskb+0x85/0x200 process_backlog+0x374/0x9a0 _napipoll+0x4f/0x1c0 netrxaction+0x3b0/0x770 handlesoftirqs+0x15a/0x460 dosoftirq+0x57/0x80 </IRQ>

The rmem charge that devscratch accounted for is released by skbrecvudp() on dequeue, just above, so the scratch is dead by the time recvactor() runs. Clear skb->dev so bpfskclookup() falls back to socknet(skb->sk), which skbsetownersk_safe() set just above.(CVE-2026-53184)

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

RDMA/srp: bound SRP_RSP sense copy by the received length

srpprocessrsp() copies sense data from rsp->data + respdatalen, where respdatalen is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->bytelen). The copy length is bounded to SCSISENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.

A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRPRSP with SRPRSPFLAGSNSVALID set and a large respdatalen. The receive buffer is allocated at the target-chosen maxtiiulen, so the source of the sense copy lands past the bytes actually received; with respdata_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.

Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->bytelen; this brings ibsrp into line with them.(CVE-2026-53186)

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

drm/virtio: fix dmafence refcount leak on error in virtiogpudmafence_wait()

dmafenceunwrapforeach() internally calls dmafenceunwrapfirst() which does cursor->chain = dmafenceget(head), taking an extra reference. On normal loop completion, dmafenceunwrapnext() releases this via dmafencechainwalk() -> dmafence_put().

When virtiogpudofencewait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dmafenceunwrapforeach.

Add dmafenceput(itr.chain) before the early return.(CVE-2026-53190)

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

mm/memory-failure: fix hugetlblock AA deadlock in gethugepagefor_hwpoison

Two concurrent madvise(MADVHWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlblock when racing with a concurrent unmap:

thread#0 thread#1 -------- -------- madvise(folio, MADVHWPOISON) -> poisons the folio successfully madvise(folio, MADVHWPOISON) unmap(folio) trymemoryfailurehugetlb gethugepageforhwpoison spinlockirq(&hugetlblock) <- held __gethugepageforhwpoison hugetlbupdatehwpoison() -> MFHUGETLBFOLIOPREPOISONED goto out: folioput() refcount: 1 -> 0 freehugefolio() spinlockirqsave(&hugetlblock) -> AA DEADLOCK!

The out: path in __gethugepageforhwpoison() calls folioput() to drop the GUP reference while the hugetlblock is still held by the hugetlb.c wrapper gethugepageforhwpoison(). If concurrent unmap has released the page table mapping reference, folioput() drops the folio refcount to zero, triggering freehugefolio() which attempts to re-acquire the non-recursive hugetlblock.

Fix this by moving hugetlblock acquisition from the hugetlb.c wrapper into gethugepageforhwpoison(). Place spinunlockirq() before the folioput() at the out: label so the folio is always released outside the lock.

[(CVE-2026-53207)

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

netfilter: nftexthdr: fix register tracking for FPRESENT flag

nftexthdrinit() passes user-controlled priv->len to nftparseregisterstore(), which marks that many bytes in the register bitmap as initialized. However, when NFTEXTHDRFPRESENT is set, the eval paths write only 1 byte (nftregstore8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs.

Bail out if userspace requests too much data when F_PRESENT is set.(CVE-2026-53218)

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

netfilter: x_tables: avoid leaking percpu counter pointers

The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.

On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.

Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.(CVE-2026-53219)

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

netfilter: revalidate bridge ports

ebtredirecttg() dereferences brportget_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject.

A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan.

If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path.

Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact:

Both nfnetlinklog and nfnetlinkqueue use CONFIGBRIDGENETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTERFAMILYBRIDGE can be enabled while the old CONFIGBRIDGENETFILTER cruft is off.

Fixes tag is a common ancestor, this was always broken.(CVE-2026-53220)

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

ip6vti: fix incorrect tunnel matching in vti6tnl_lookup()

In vti6tnllookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels:

• Tunnels matching the packet's local address, with any remote address wildcard remote).

• Tunnels matching the packet's remote address, with any local address (wildcard local).

However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnlsrl) prone to hash collisions.

The bug is that the fallback search loops in vti6tnllookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.(CVE-2026-53221)

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

net: guard timestamp cmsgs to real error queue skbs

skbiserrqueue() treats PACKETOUTGOING as the sole marker for an skb from skerrorqueue. That assumption is not true for AFPACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkttype == PACKETOUTGOING, but their skb->cb is owned by AFPACKET instead of struct sockexterrskb.

If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AFPACKET control-buffer state as sockexterrskb::optstats. With SORXQOVFL enabled, the packet drop counter overlaps optstats. An odd drop count makes the path emit SCMTIMESTAMPINGOPTSTATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents.

Keep skbiserrqueue() local to net/socket.c, but make it verify that the PACKETOUTGOING marker is paired with the sockrmemfree destructor installed by sockqueueerrskb(). AFPACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate skerrorqueue entries keep the PACKETOUTGOING marker and sockrmem_free ownership.(CVE-2026-53223)

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

net: openvswitch: fix possible kfreeskb of ERRPTR

After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex.

However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking.

If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer.

Fix this by setting the pointer to NULL after having saved its error value.(CVE-2026-53227)

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

ipv6: sit: reload inner IPv6 header after GSO offloads

ipip6tunnelxmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnelhandleoffloads().

For GSO skbs, iptunnelhandleoffloads() calls skbheaderunclone(). When the skb header is cloned, skbheaderunclone() can call pskbexpandhead(), which may move the skb head. The pskbexpandhead() contract requires pointers into the skb header to be reloaded after the call.

If the later skbreallocheadroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released.

Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skbreallocheadroom(), since that branch can also replace the skb.(CVE-2026-53228)

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

net/mlx5e: xsk: Fix DMA and xdpframe leak on XDPTX xmit failure

In the XSK branch of mlx5exmitxdpbuff(), when sq->xmitxdpframe() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdpframe allocated by xdpconvertzctoxdpframe(). The xdpififo push only happens on success, so the completion path cannot recover these entries.

With CONFIGDMAAPI_DEBUG=y, the leak surfaces on driver unbind:

DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMATODEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dmadebugdevicechange+0x127/0x180 ... DMA-API: Mapped at: debugdmamapphys+0x4b/0xd0 dmamapphys+0xfd/0x2d0 mlx5exdphandle+0x5ae/0xac0 [mlx5core] mlx5exskskbfromcqempwrqlinear+0xc4/0x170 [mlx5core] mlx5ehandlerxcqempwrq+0xc1/0x290 [mlx5_core]

Add the missing unmap + xdpreturnframe, matching the cleanup already done in mlx5exdpxmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.(CVE-2026-53229)

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

net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmac_list

mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:

BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385

CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>

Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.(CVE-2026-53230)

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

tcp: restrict SOATTACHFILTER to priv users

This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.

This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.(CVE-2026-53236)

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

netlabel: validate unlabeled address and mask attribute lengths

netlblunlabeladdrinfoget() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct inaddr or struct in6_addr.

NLABINARY policy lengths are maximum lengths by default, so use NLAPOLICYEXACTLEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.(CVE-2026-53238)

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

xfrm: policy: fix use-after-free on inexact bin in xfrmpolicybysel_ctx()

Fix the race by pruning the bin while still holding xfrmpolicylock, before dropping it. Use __xfrmpolicyinexactprunebin() directly since the lock is already held. The wrapper xfrmpolicyinexactprunebin() becomes unused and is removed.

Race:

CPU0 (XFRMMSGDELPOLICY) CPU1 (XFRMMSGNEWSPDINFO) ========================== ========================== xfrmpolicybyselctx(): spinlockbh(xfrmpolicylock) bin = xfrmpolicyinexactlookup() __xfrmpolicyunlink(pol) spinunlockbh(xfrmpolicylock) xfrmpolicykill(ret) // wide window, lock not held xfrmhashrebuild(): spinlockbh(xfrmpolicylock) __xfrmpolicyinexactflush(): kfreercu(bin) // bin freed spinunlockbh(xfrmpolicylock) xfrmpolicyinexactprunebin(bin) // UAF: bin is freed(CVE-2026-53239)

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

ALSA: PCM: Fix wait queue list corruption in sndpcmdrain() on linked streams

sndpcmdrain() uses initwaitqueueentry which does not clear entry.prev/next, and addwaitqueue with a conditional removewaitqueue that is skipped when tocheck is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, addwaitqueue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wakeup dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted waitqueuehead_t), causing a kernel panic.

Replace initwaitqueueentry/addwaitqueue/conditional removewaitqueue with initwaitentry/preparetowait/ finishwait. initwaitentry clears prev/next via INITLISTHEAD on each iteration and sets autoremovewakefunction which auto-removes the entry on wake-up. finishwait safely handles both the already-removed and still-queued cases.(CVE-2026-53242)

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

net/802/mrp: fix vector attribute parsing in mrppduparse_vecattr

In mrppduparse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process.

The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state.

Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing.

Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value.

Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.(CVE-2026-53245)

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

sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing

When a listening SCTP server processes a COOKIEECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctpprocessinit() using sctpwalk_params().

However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIEECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATECOOKIE processing and kmemdup() copies).

Add a bounds check in sctpunpackcookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.(CVE-2026-53246)

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.

This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.

While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.

RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.(CVE-2026-53249)

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

Bluetooth: fix memory leak in error path of hciallocdev()

Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory.

When device initialization fails before hciregisterdev() completes, the HCIUNREGISTER flag is never set. As a result, when the device reference count reaches zero, bthost_release() evaluates this flag as false and falls back to a direct kfree(hdev).

Because hcireleasedev() is bypassed, the SRCU struct initialized early in hciallocdev() is never cleaned up, resulting in a leak of percpu memory.

Fix the leak by explicitly calling cleanupsrcustruct() in the fallback (unregistered) branch of bthostrelease() before freeing the device.(CVE-2026-53252)

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

Bluetooth: bnep: reject short frames before parsing

A BNEP peer can send a short BNEP SDU. bneprxframe() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bneprxcontrol() also dereferences the control opcode without rejecting an empty control payload.

Use skbpulldata() for the fixed fields in bneprxframe() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads.

For BNEPSETUPCONNREQ, name the UUID-size byte before pulling the setup payload. struct bnepsetupconnreq carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication.

Validation reproduced this kernel report: KASAN slab-out-of-bounds in bneprxframe.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dumpstacklvl+0xb3/0x140 (?:?) printaddressdescription+0x57/0x3a0 (?:?) bneprxframe+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virtaddrvalid+0x1ba/0x3a0 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) kasanaddrtoslab+0x21/0x60 (?:?) kasanreport+0xe0/0x110 (?:?) processonework+0xfce/0x17e0 (kernel/workqueue.c:3200) workerthread+0x65c/0xe40 (?:?) __kthreadparkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) rawspinunlock_irq+0x28/0x50 (?:?) retfromfork+0x586/0x870 (?:?) __switchto+0x74f/0xdc0 (?:?) retfromforkasm+0x1a/0x30 (?:?)(CVE-2026-53253)

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

Bluetooth: RFCOMM: validate skb length in MCC handlers

The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers.

Fix this by using skbpulldata() to validate and access the required data before dereferencing it.

rfcommrecvrpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.(CVE-2026-53254)

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

Bluetooth: MGMT: validate advertising TLV before type checks

tlvdatais_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer.

A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data.

KASAN reported the following when a malformed MGMTOPADD_ADVERTISING request reached that path:

BUG: KASAN: vmalloc-out-of-bounds in tlvdataisvalid() Read of size 1 Call trace: tlvdataisvalid() addadvertising() hcimgmtcmd() hcisock_sendmsg()

Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].(CVE-2026-53255)

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

Bluetooth: RFCOMM: hold listener socket in rfcommconnectind()

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

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

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

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

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

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

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

net/sched: act_api: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfree_rcu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.(CVE-2026-53264)

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

netfilter: bridge: make ebt_snat ARP rewrite writable

The ebtables SNAT target keeps the Ethernet source address rewrite behind skbensurewritable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skbmacheader()/ethhdr(), while skb->data points at the Ethernet payload. Asking skbensurewritable() for ETHHLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a.

However, the optional ARP sender hardware address rewrite is different. It writes through skbstorebits() at an offset relative to skb->data:

    skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)

skbheaderpointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skbstorebits() maps the frag page and copies the new MAC address directly into it.

Ensure the ARP SHA range is writable before reading the ARP header and before calling skbstorebits().(CVE-2026-53266)

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

netfilter: nft_ct: bail out on template ct in get eval

I noticed this issue while looking at a historic syzbot report [1].

A rule like the one below is enough to trigger the bug:

table ip t {
    chain pre {
        type filter hook prerouting priority raw;
        ct zone set 1
        ct original saddr 1.2.3.4 accept
    }
}

The first expression attaches a per-cpu template ct via nftctsetzoneeval() (nfcttmplalloc -> kzalloc, tuple is all zero, nfctl3num(ct) == 0). The next expression then calls nftctgeteval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFTREG3215 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.

Reject template ct at the eval entry and in nftctgetfasteval(), mirroring the check nftctseteval() already has. Additionally, bound the address copy in NFTCTSRC / NFTCTDST by priv->len instead of by nfctl3num(ct): nfctgettuple() zeroes the tuple before pkttotuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.

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

netfilter: synproxy: add mutex to guard hook reference counting

As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.

Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.(CVE-2026-53269)

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

ipvs: clear the svc scheduler ptr early on edit

ipvseditservice() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->scheddata is already freed after RCU grace period.

Fix it by clearing the ptr early in ipvsunbindscheduler(), before the doneservice method schedules any RCU callbacks.

Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.(CVE-2026-53270)

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

net: bonding: fix NULL pointer dereference in bonddoioctl()

In bonddoioctl(), slave_dev is obtained via __devgetbyname() which can return NULL if the requested interface name does not exist. However, the subsequent slavedbg() call is placed before the NULL check:

slave_dev = __dev_get_by_name(net, ifr->ifr_slave);
slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here
if (!slave_dev)
    return -ENODEV;

The slavedbg() macro expands to netdevdbg(bonddev, "(slave %s): " fmt, (slavedev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name.

This is reachable from userspace via the bonding ioctl interface with CAPNETADMIN capability, making it a potential local denial-of-service vector.

Fix by moving the slave_dbg() call after the NULL check.(CVE-2026-53337)

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

netfilter: nf_conntrack: destroy stale expectfn expectations on unregister

NAT helpers such as nfnath323 store a raw pointer to module text in exp->expectfn (e.g. ipnatq931expect). nfcthelperexpectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text.

When the expected connection arrives, initconntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nfnat_h323, then connecting to the expected port:

Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 initconntrack.isra.0 (net/netfilter/nfconntrackcore.c:1862) nfconntrackin (net/netfilter/nfconntrackcore.c:2049) ipv4conntracklocal (net/netfilter/nfconntrackproto.c:223) nfhook_slow (net/netfilter/core.c:619) __iplocalout (net/ipv4/ip_output.c:120) __tcptransmitskb (net/ipv4/tcpoutput.c:1715) tcpconnect (net/ipv4/tcpoutput.c:4374) tcpv4connect (net/ipv4/tcpipv4.c:345) _sysconnect (net/socket.c:2167) Modules linked in: nfconntrackh323 [last unloaded: nfnath323]

Reaching the dangling state requires CAPSYSMODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless.

Add nfcthelperexpectfndestroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.(CVE-2026-53349)

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

Bluetooth: fix UAF in l2capsockcleanuplisten() vs l2capconn_del()

btacceptdequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked.

l2capsockcleanuplisten() walks these children on listening-socket close. A concurrent HCI disconnect drives hcirxwork -> l2capconndel() which runs l2capchandel() + l2capsockkill() and frees the child sk and its l2capchan; cleanup_listen() then uses both:

BUG: KASAN: slab-use-after-free in l2capsockkill l2capsockkill / l2capsockcleanup_listen / _x64sysclose Freed by: l2capconndel -> l2capsockclosecb -> l2capsockkill

This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize acceptq access") serialises the acceptq list/poll and takes temporary refs inside btacceptdequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanuplisten() under locksock() in l2capsockrelease(). Neither covers l2capconndel() running from hcirxwork, so this UAF still reproduces on current bluetooth/master.

Take the reference at the source: btacceptdequeue() does sockhold() while sk is still locked, before releasesock(); callers sockput(). cleanuplisten() pins the chan with l2capchanholdunlesszero() under a brief child sk lock (serialising vs l2capsockteardowncb()), drops it before l2capchanlock(), and skips a duplicate l2capsockkill() on SOCKDEAD. conn->lock is not taken here: cleanuplisten() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sklock (lockdep).

KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.(CVE-2026-53357)

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

Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()

l2capchanclose() removes the channel from conn->chanl, which must be done under conn->lock. cleanuplisten() runs under the parent sklock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sklock order.

Instead of calling l2capchanclose() directly, schedule l2capchantimeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order.

The timer is only armed when chan->conn is still set: if it is already NULL, l2capconndel() has already processed this channel (l2capchandel + l2capsockteardowncb + l2capsockclosecb), so there is nothing left to do. If l2capconndel() races in after the timer is armed, __clearchantimer() inside l2capchandel() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.(CVE-2026-53358)

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

KVM: x86: Fix shadow paging use-after-free due to unexpected role

Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmapremove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvmmmu_page.

A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvmmmupage with direct=1, while the new 4KB needs a kvmmmupage with direct=0. However, kvmmmugetchildsp() does not compare the role, and therefore reuses the page.

The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvmmmupage has direct=1 and kvmmmupagegetgfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry.

When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.(CVE-2026-53359)

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

blk-cgroup: fix UAF in __blkcgrstatflush()

When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcgrstatflush() removes another blkg's iostat entries via llistdelall(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries.

Move the flush from _blkgrelease() (RCU callback) to blkgrelease() (before callrcu). This ensures the RCU grace period waits for any concurrent flush's rcureadlock() section to complete before freeing.(CVE-2026-63802)

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

Bluetooth: hcisync: Set HCICMDDRAINWORKQUEUE during device close

Since hcidevclosesync() can now be called during the reset path, we should also set HCICMDDRAINWORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.(CVE-2026-63974)

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconn_rsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)

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

irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT

On PREEMPTRT, non-HARD irqwork runs in per-CPU kthreads via runirqworkd(), so irqworksync() uses rcuwait() to wait for BUSY==0.

After irqworksingle() clears BUSY via atomiccmpxchg(), it still dereferences @work for irqworkishard() and rcuwaitwakeup().

An irqworksync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.

Fix this by wrapping runirqworkd() in guard(rcu)() so that the entire irqworksingle() execution is within an RCU read-side critical section. Then add synchronizercu() in irqworksync() after rcuwaitwait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.(CVE-2026-64073)

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

rbd: eliminate a race in lock_dwork draining on unmap

Given how rbdlockaddrequest() and rbdimgexclusivelock() are written, lockdwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbdacquirelock() on behalf of another I/O request. This is expected and with rbdreleaselock() preemptively canceling lockdwork is benign under normal operation.

A more problematic example is maybekickacquire():

if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
        dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
        mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}

It's not unrealistic for lockdwork to get canceled right after delayedworkpending() returns true and for moddelayed_work() to requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbddevimageunlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lockdwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lockdwork is canceled only in canceltaskssync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybekickacquire(). This may result in rbdacquirelock() executing after rbddevdevicerelease() and rbddevimage_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbd_assert(rbd_image_format_valid(rbd_dev->image_format));

in rbddevheaderinfo() which is called via rbddevrefresh() from rbdpostacquireaction().

Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbddevimage_unlock().(CVE-2026-64112)