The Linux Kernel, the operating system core itself.

Security Fix(es):

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

btrfs: qgroup: fix race between quota disable and quota rescan ioctl

There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fsinfo->qgrouptree rbtree.

This happens as follows:

1) Task A enters btrfsioctlquotarescan() -> btrfsqgroup_rescan();

2) Task B enters btrfsquotadisable() and calls btrfsqgroupwaitforcompletion(), which does nothing because at that point fsinfo->qgrouprescan_running is false (it wasn't set yet by task A);

3) Task B calls btrfsfreeqgroupconfig() which starts freeing qgroups from fsinfo->qgrouptree without taking the lock fsinfo->qgroup_lock;

4) Task A enters qgrouprescanzerotracking() which starts iterating the fsinfo->qgrouptree tree while holding fsinfo->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.

Fix this by taking fsinfo->qgrouplock at btrfsfreeqgroupconfig(). Also at btrfsqgroup_rescan() don't start the rescan worker if quotas were already disabled.(CVE-2025-39759)

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

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

drivers/net/wireless/microchip/wilc1000/wlancfg.c:184 wilcwlanparseresponse_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilccfgstrvals' that is maintained in 'len' field of 'struct wilccfg_str'.(CVE-2025-39952)

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

iio: accel: bmc150: Fix irq assumption regression

The code in bmc150-accel-core.c unconditionally calls bmc150accelsetinterrupt() in the iiobuffersetupops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:

Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read

PC is at bmc150accelset_interrupt+0x98/0x194 LR is at __pmruntimeresume+0x5c/0x64 (...) Call trace: bmc150accelsetinterrupt from bmc150accelbufferpostenable+0x40/0x108 bmc150accelbuffer_postenable from __iioupdatebuffers+0xbe0/0xcbc _iioupdatebuffers from enablestore+0x84/0xc8 enablestore from kernfsfopwriteiter+0x154/0x1b4

This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.

Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.(CVE-2025-68330)

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

staging: most: remove broken i2c driver

The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging.

Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.(CVE-2025-68755)

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

btrfs: fix NULL dereference on root when tracing inode eviction

When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfsevictinode() the root might be NULL, as implied in the next check that we do in btrfsevictinode().

Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.(CVE-2025-71184)

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

fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO

Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31605)

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

usbip: validate numberofpackets in usbippackret_submit()

When a USB/IP client receives a RETSUBMIT response, usbippackretsubmit() unconditionally overwrites urb->numberofpackets from the network PDU. This value is subsequently used as the loop bound in usbiprecviso() and usbippadiso() to iterate over urb->isoframedesc[], a flexible array whose size was fixed at URB allocation time based on the original numberofpackets from the CMD_SUBMIT.

A malicious USB/IP server can set numberofpackets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbiprecviso() writes to urb->isoframedesc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbiprecviso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stubrx.c) and gadget side (vudcrx.c) already validate numberofpackets in the CMDSUBMIT path since commits c6688ef9f297 ("usbip: fix stubrx: harden CMDSUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudcrx: harden CMDSUBMIT path to handle malicious input"). The server side validates against USBIPMAXISOPACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original numberofpackets.

This mirrors the existing validation of actuallength against transferbufferlength in usbiprecv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbiprecviso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbippackretsubmit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIPMAXISOPACKETS limit.

Fix this by checking rpdu->numberofpackets against urb->numberofpackets in usbippackretsubmit() before the overwrite. On violation, clamp to zero so that usbiprecviso() and usbippad_iso() safely return early.(CVE-2026-31607)

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

usb: gadget: renesas_usb3: validate endpoint index in standard request handlers

The GETSTATUS and SET/CLEARFEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.

This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.(CVE-2026-31615)

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

usb: gadget: fphonet: fix skb frags[] overflow in pnrx_complete()

A broken/bored/mean USB host can overflow the skbsharedinfo->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers.

pnrxcomplete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGESIZE by the gadget. If the host always sends exactly PAGESIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skbaddrxfrag(). Once nrfrags exceeds MAXSKBFRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap.

Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path").(CVE-2026-31616)

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

usb: gadget: fncm: validate minimum blocklen in ncmunwrapntb()

The blocklen read from the host-supplied NTB header is checked against ntbmax but has no lower bound. When blocklen is smaller than opts->ndpsize, the bounds check of: ndpindex > (blocklen - opts->ndpsize) will underflow producing a huge unsigned value that ndpindex can never exceed, defeating the check entirely.

The same underflow occurs in the datagram index checks against blocklen - opts->dpesize. With those checks neutered, a malicious USB host can choose ndpindex and datagram offsets that point past the actual transfer, and the skbput_data() copies adjacent kernel memory into the network skb.

Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make blocklen - opts->ndpsize and blocklen - opts->dpesize both well-defined.

Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM.(CVE-2026-31617)

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

fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO

Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31618)

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

net/packet: fix TOCTOU race on mmap'd vnethdr in tpacketsnd()

In tpacketsnd(), when PACKETVNETHDR is enabled, vnethdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packetsndvnetparse() but then re-reads all fields later in virtionethdrtoskb(). A concurrent userspace thread can modify the vnethdr fields between validation and use, bypassing all safety checks.

The non-TPACKET path (packetsnd()) already correctly copies vnethdr to a stack-local variable. All other vnethdr consumers in the kernel (tun.c, tap.c, virtionet.c) also use stack copies. The TPACKET TX path is the only caller of virtionethdrtoskb() that reads directly from user-controlled shared memory.

Fix this by copying vnethdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packetsnd() and all other callers.(CVE-2026-31700)

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

Buffer overflow in drivers/xen/sys-hypervisor.c

The build id returned by HYPERVISORxenversion(XENVERbuildid) is neither NUL terminated nor a string.

The first causes a buffer overflow as sprintf in buildid_show will read and copy till it finds a NUL.

00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P| 00000010 b9 a8 01 42 6f 2e 32 |...Bo.2| 00000017

So use a memcpy instead of sprintf to have the correct value:

00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P| 00000010 b9 a8 01 42 |...B| 00000014

(the above have a hack to embed a zero inside and check it's returned correctly).

This is XSA-485 / CVE-2026-31786(CVE-2026-31786)

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

crypto: algif_aead - Fix minimum RX size check for decryption

The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length.(CVE-2026-43077)

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

crypto: afalg - Fix page reassignment overflow in afalgpulltsgl

When page reassignment was added to afalgpull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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:

xsk: tighten UMEM headroom validation to account for tailroom and min frame

The current headroom validation in xdpumemreg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skbsharedinfo stored at the end of XSK frame would be corrupted.

HW typically works with 128-aligned sizes so let us provide this value as bare minimum.

Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.(CVE-2026-43093)

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:

iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode

Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pcidevis_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system.

For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd.

Call Trace: qisubmitsync qiflushdeviotlb intelpasidteardownentry deviceblocktranslation blockingdomainattachdev __iommuattachdevice __iommudeviceset_domain __iommugroupsetdomaininternal iommudetachgroup vfioiommutype1detachgroup vfiogroupdetachcontainer vfiogroupfopsrelease __fput

Although pcideviceispresent() is slower than pcidevisdisconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase.

Besides, devtlbinvalidationwith_pasid() is called only in the paths below, which are far less frequent than memory map/unmap.

1. mm-struct release
2. {attach,release}_dev
3. set/remove PASID
4. dirty-tracking setup

The gain in system stability far outweighs the negligible cost of using pcideviceispresent() instead of pcidevisdisconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.(CVE-2026-43130)

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

xfrm6: fix uninitialized saddr in xfrm6getsaddr()

xfrm6getsaddr() does not check the return value of ipv6devgetsaddr(). When ipv6devgetsaddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6getsaddr() still returns 0 (success).

This causes the caller xfrmtmplresolveone() to use the uninitialized address in xfrmstate_find(), triggering KMSAN warning:

===================================================== BUG: KMSAN: uninit-value in xfrmstatefind+0x2424/0xa940 xfrmstatefind+0x2424/0xa940 xfrmresolveandcreatebundle+0x906/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 xfrmlookuproute+0x63/0x2b0 iprouteoutputflow+0x1ce/0x270 udpsendmsg+0x2ce1/0x3400 inetsendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64syssendto+0x130/0x200 x64syscall+0x332b/0x3e70 dosyscall64+0xd3/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable tmp.i.i created at: xfrmresolveandcreatebundle+0x3e3/0x5a20

xfrmlookupwith_ifid+0xcc0/0x3770

Fix by checking the return value of ipv6devget_saddr() and propagating the error.(CVE-2026-43139)

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

netfilter: xt_tcpmss: check remaining length before reading optlen

Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length.

If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).(CVE-2026-43190)

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

tcp: fix potential race in tcpv6synrecvsock()

Code in tcpv6synrecvsock() after the call to tcpv4synrecvsock() is done too late.

After tcpv4synrecvsock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcpv6mappedchildinit() and call this new helper from tcpv4synrecvsock() before the ehash insertion.

This allows the removal of one tcpsyncmss(), since tcpv4synrecvsock() will call it with the correct context.(CVE-2026-43198)

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

netfilter: nfconntrackh323: fix OOB read in decode_choice()

In decodechoice(), the boundary check before getlen() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0;
...
if (ext || (son->attr & OPEN)) {
    BYTE_ALIGN(bs);
    if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */
        return H323_ERROR_BOUND;
    len = get_len(bs);                        /* OOB read */

When the bitstream is exactly consumed (bs->cur == bs->end), the check nfh323errorboundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent getlen() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nfconntrackh323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that getlen() may read) instead of the uninitialized len. This matches the pattern used at every other getlen() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().(CVE-2026-43233)

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

iommu/amd: move waitonsem() out of spinlock

With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as waitonsem() busy-waits under the spinlock with interrupts disabled.

Move the completion wait in iommucompletionwait() out of the spinlock. waitonsem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled.(CVE-2026-43253)

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:

ipv6: prevent possible UaF in addrconfpermanentaddr()

The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion.

Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.(CVE-2026-43339)

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

net/tcp-md5: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2026-43383)

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

netfilter: nfnetlinkcthelper: fix OOB read in nfnlcthelperdumptable()

nfnlcthelperdumptable() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nfcthelperhsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nfcthelperhash[nfcthelperhsize].

The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds.

BUG: KASAN: slab-out-of-bounds in nfnlcthelperdumptable+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poccthelper/131 Call Trace: nfnlcthelperdumptable+0x9f/0x1b0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 sockrecvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64sysrecvfrom+0x76/0x90 dosyscall64+0xc3/0x6e0

Allocated by task 1: __kvmallocnodenoprof+0x21b/0x700 nfctallochashtable+0x65/0xd0 nfconntrackhelperinit+0x21/0x60 nfconntrackinitstart+0x18d/0x300 nfconntrackstandaloneinit+0x12/0xc0(CVE-2026-43450)

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

netfilter: x_tables: guard option walkers against 1-byte tail reads

When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area.

Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xttcpudp and xtdccp option walkers.(CVE-2026-43452)

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

netfilter: nftsetpipapo: fix stack out-of-bounds read in pipapo_drop()

pipapodrop() passes rulemap[i + 1].n to pipapounmap() as the tooffset argument on every iteration, including the last one where i == m->fieldcount - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFTPIPAPOMAXFIELDS] with NFTPIPAPOMAXFIELDS == 16).

Although pipapounmap() returns early when islast is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN:

BUG: KASAN: stack-out-of-bounds in pipapodrop+0x50c/0x57c [nftables] Read of size 4 at addr ffff8000810e71a4

This frame has 1 object: [32, 160) 'rulemap'

The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array.

Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.(CVE-2026-43453)

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

rtmutex: Use waiter::task instead of current in remove_waiter()

removewaiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rtmutexstartproxylock() when invoked from futexrequeue().

In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems:

1) the rbtree dequeue happens without waiter::task::pi_lock being held

2) the waiter task's piblockedon state is not cleared, which leaves a dangling pointer primed for UAF around.

3) rtmutexadjustpriochain() operates on the wrong top priority waiter task

Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems.

tglx: Fixup rtmutexadjustpriochain(), add a comment and amend the changelog

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

openvswitch: cap upcall PID array size and pre-size vport replies

The vport netlink reply helpers allocate a fixed-size skb with nlmsgnew(NLMSGDEFAULTSIZE, ...) but serialize the full upcall PID array via ovsvportgetupcallportids(). Since ovsvportsetupcallportids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAPNETADMIN user can install a PID array large enough to overflow the reply buffer, causing nlaput() to fail with -EMSGSIZE and hitting BUGON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENLUNSADMINPERM.

kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovsvportcmdset+0x34c/0x400 Call Trace: <TASK> genlfamilyrcvmsgdoit (net/netlink/genetlink.c:1116) genlrcvmsg (net/netlink/genetlink.c:1194) netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK> Kernel panic - not syncing: Fatal exception

Reject attempts to set more PIDs than nrcpuids in ovsvportsetupcallportids(), and pre-compute the worst-case reply size in ovsvportcmdmsgsize() based on that bound, similar to the existing ovsdpcmdmsgsize(). nrcpuids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovsdpcmdfillinfo() serialises at most nrcpuids PIDs), so the two sides stay consistent.(CVE-2026-45840)

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

slip: bound decode() reads against the compressed packet length

slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code.

A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets.

Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.(CVE-2026-45843)

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

RDMA/rxe: Fix double free in rxesrqfrom_init

In rxesrqfrominit(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copytouser() fails, the function calls rxequeue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'.

The caller of rxesrqfrominit() (rxecreatesrq) eventually calls rxesrqcleanup() upon receiving the error, which triggers a second rxequeue_cleanup() on the same memory, leading to a double free.

The call trace looks like this: kmemcachefree+0x.../0x... rxequeuecleanup+0x1a/0x30 [rdmarxe] rxesrqcleanup+0x42/0x60 [rdmarxe] rxeelemrelease+0x31/0x70 [rdmarxe] rxecreatesrq+0x12b/0x1a0 [rdmarxe] ibcreatesrquser+0x9a/0x150 [ibcore]

Fix this by moving 'srq->rq.queue = q' after copytouser.(CVE-2026-45852)

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

iommu/vt-d: Flush cache for PASID table before using it

When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.(CVE-2026-45862)

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the PASID entry.
2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dmawmb() in pasidset_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

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

xfrm: fix iprtbug race in icmproutelookup reverse path

icmproutelookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies.

The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrmlookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrmdecodesessionreverse() to get fl4dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4dec.saddr is local (we are the original destination), use _iprouteoutputkey() for output route lookup 6. If fl4dec.saddr is NOT local (we are a forwarding node), use iprouteinput() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrmlookup() with XFRMLOOKUPICMP flag

The bug occurs in step 6: iprouteinput() is called with fl4dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and iprouteinput() call (e.g., due to concurrent "ip addr add"), iprouteinput() returns a LOCAL route with dst.output set to iprt_bug.

This route is then used for ICMP output, causing dstoutput() to call iprtbug(), triggering a WARNON:

------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at iprtbug+0x21/0x30, CPU#1 Call Trace: <TASK> ippushpendingframes+0x202/0x240 icmppush_reply+0x30d/0x430 __icmpsend+0x1149/0x24f0 ipoptionscompile+0xa2/0xd0 iprcvfinishcore+0x829/0x1950 ip_rcv+0x2d7/0x420 _netifreceiveskbonecore+0x185/0x1f0 netifreceiveskb+0x90/0x450 tungetuser+0x3413/0x3fb0 tunchrwriteiter+0xe4/0x220 ...

Fix this by checking rt2->rttype after iprouteinput(). If it's RTNLOCAL, the route cannot be used for output, so treat it as an error.

The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at:

https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81(CVE-2026-45905)

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

Revert "hwmon: (ibmpex) fix use-after-free in high/low store"

This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.

Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.

Various AI reviews agree. Specific and relevant AI feedback:

" This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.

ibmpexshowsensor() retrieves this driver data via devgetdrvdata() but does not check if it is NULL before dereferencing it to access data->sensors[].

If a userspace process reads a sensor file (like temp1input) while this delete function is running, could it race with the devsetdrvdata(..., NULL) call here and crash in ibmpexshow_sensor()?

Would it be safer to keep the original order where deviceremovefile() is called before clearing the driver data? deviceremovefile() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. "

Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.(CVE-2026-45914)

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

fat: avoid parent link count underflow in rmdir

Corrupted FAT images can leave a directory inode with an incorrect inlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls dropnlink(dir) and can drive inlink to 0, triggering the WARNON in drop_nlink().

Add a sanity check in vfatrmdir() and msdosrmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

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

sched/rt: Skip currently executing CPU in rtonextcpu()

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVERTPUSHIPI enabled, they send IPIs to CPU0 to drive the execution of rtopushirqworkfunc. During pushrttask on CPU0, if nexttask->prio < rq->donor->prio, reschedcurr() sets NEEDRESCHED and after the push operation completes, CPU0 calls rtonextcpu(). Since only CPU0 is overloaded in this scenario, rtonextcpu() should ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tellcputopush() during LB increments rd->rtoloopnext. Even when rd->rtocpu is set to -1, the mismatch between rd->rtoloop and rd->rtoloopnext forces rtonextcpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rtnrmigratory && rtnrtotal > 1), it gets reselected, causing CPU0 to queue irqwork to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pullrttasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.

The trigging scenario is as follows:

     cpu0                      cpu1                    cpu2
                            pull_rt_task
                          tell_cpu_to_push
             <------------irq_work_queue_on

rtopushirqworkfunc pushrttask reschedcurr(rq) pullrttask rtonextcpu tellcputopush <-------------------------- atomicinc(rtoloopnext) rd->rtoloop != next rtonextcpu irqworkqueueon rtopushirqwork_func

Fix redundant self-IPI by filtering the initiating CPU in rtonextcpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)

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

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4putsuper() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4putsuper+0x48c/0x590 [ext4]

Tracing the failure shows that the warning fires due to an sdirtyclusterscounter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4mbmarkdiskspaceused() and the caller ext4mbnew_blocks().

First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4handledirtymetadata() call(s) made from ext4mbmarkcontext(). The changed value is non-zero at this point, so ext4mbmarkdiskspaceused() does not exit after the error bubbles up from ext4mbmarkcontext(). Instead, the former decrements both cluster counters and returns the error up to ext4mbnewblocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.

To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4mbnewblocks() is responsible for acquiring cluster reservation (via ext4claimfreeclusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)

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

fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot

In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking.

Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize);

It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow.

This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.(CVE-2026-45935)

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

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
4. Fully zero out the entry only after the invalidation is complete.

Also, add a dmawmb() to contextset_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

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

ext4: fix memory leak in ext4extshift_extents()

In ext4extshiftextents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4find_extent(), leading to a memory leak.

Fix this by jumping to the out label to ensure the path is properly released.(CVE-2026-45948)

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

nfsd: never defer requests during idmap lookup

During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped.

This prevents nfs4svcencodecompoundres from being executed, and thus the session slot flag NFSD4SLOTINUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail.

Fix this by making sure that the RQUSEDEFERRAL flag is always clear during nfs4svcdecode_compoundargs(), since no v4 request should ever be deferred.(CVE-2026-45983)

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

ext4: don't set EXT4GETBLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with dioreadnolock enabled, EXT4GETBLOCKSPREIO was set to split an existing large unwritten extent. However, EXT4GETBLOCKSCONVERT was set when calling ext4splitconvert_extents(), which may potentially result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, ext4iomapalloc() call ext4mapblocks() with EXT4GETBLOCKSPREIO, EXT4GETBLOCKSUNWRITEXT and EXT4GETBLOCKSCREATE flags set. ext4mapblocks() find this extent and call ext4splitconvertextents() with EXT4GETBLOCKS_CONVERT and the above flags set.

Then, ext4splitconvertextents() calls ext4splitextent() with EXT4EXTMAYZEROOUT, EXT4EXTMARKUNWRIT2 and EXT4EXTDATAVALID2 flags set, and it calls ext4splitextentat() to split the second half with EXT4EXTDATAVALID2, EXT4EXTMARKUNWRIT1, EXT4EXTMAYZEROOUT and EXT4EXTMARKUNWRIT2 flags set. However, ext4splitextentat() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4EXTDATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.

[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4GETBLOCKSCONVERT when splitting an unwritten extent before submitting I/O, and make ext4splitconvertextents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.(CVE-2026-45985)

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

KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2

After VMRUN in guest mode, nestedsynccontrolfromvmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state.

intstate is also written by the CPU, specifically bit 0 (i.e. SVMINTERRUPTSHADOWMASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVMSETNESTEDSTATE preceeds KVMSETVCPUEVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVMSETVCPUEVENTS overwrites what KVMSETNESTEDSTATE restored in int_state).

However, if KVMSETVCPUEVENTS preceeds KVMSETNESTEDSTATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow).

Sync intstate to the cached vmcb12 in nestedsynccontrolfromvmcb02() to avoid this problem. With that, KVMSETNESTEDSTATE restores the correct interrupt shadow state, and if KVMSETVCPU_EVENTS follows it would overwrite it with the same value.(CVE-2026-45987)

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

udf: fix partition descriptor append bookkeeping

Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in partdescsloc[].

handlepartitiondescriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and numpartdescs keeps growing.

Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by numpartdescs. If partnum is already aligned to PARTDESCALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table.

Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.(CVE-2026-45991)

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

ALSA: usb-audio: stop parsing UAC2 rates at MAXNRRATES

parseuac2sampleraterange() caps the number of enumerated rates at MAXNRRATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex.

Stop the whole parse once the cap is reached and return the number of rates collected so far.(CVE-2026-46018)

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

dm mirror: fix integer overflow in createdirtylog()

The argument count calculation in createdirtylog() performs *args_used = 2 + param_count before validating against argc. When a user provides a paramcount close to UINTMAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent argc < *args_used check to be bypassed.

The overflowed paramcount is then passed as argc to dmdirtylogcreate(), where it can cause out-of-bounds reads on the argv array.

Fix by comparing paramcount against argc - 2 before performing the addition, following the same pattern used by parsefeatures() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.(CVE-2026-46023)

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

crypto: algif_aead - snapshot IV for async AEAD requests

AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

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

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

If loading L1's CR3 fails on a nested #VMEXIT, nestedsvmvmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nestedsvmvmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nestedsvmvmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

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

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payload_size() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRC_SIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRC_SIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRC_SIZE.(CVE-2026-46043)

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

ALSA: ctxfi: Add fallback to default RSR for S/PDIF

spdifpassthruplaybackgetresources() uses atc->pllrate as the RSR for the MSR calculation loop. However, pllrate is only updated in atcpllinit() and not in hwpllinit(), so it remains 0 after the card init.

When spdifpassthruplaybacksetup() skips atcpll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely.

Add fallback to use atc->rsr when atc->pllrate is 0. This reflects the hardware state, since hwcard_init() already configures the PLL to the default RSR.(CVE-2026-46049)

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

Bluetooth: hci_event: fix potential UAF in SSP passkey handlers

hciconn lookup and field access must be covered by hdev lock in hciuserpasskeynotifyevt() and hcikeypressnotifyevt(), otherwise the connection can be freed concurrently.

Extend the hcidevlock critical section to cover all conn usage in both handlers.

Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.(CVE-2026-46056)

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fbdeferrediostate. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fbinfo and the contained deferred I/O meanwhile goes away, clear struct fbdeferredio_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)

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

spi: fix resource leaks on device setup failure

Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().(CVE-2026-46083)

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

ALSA: control: Validate buflen before strnlen() in sndctleleminitenumnames()

sndctleleminitenumnames() advances pointer p through the names buffer while decrementing buflen. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0).

While strnlen(p, 0) returns 0 and would hit the existing namelen == 0 error path, CONFIGFORTIFY_SOURCE's fortified strnlen() first checks maxlen against _builtindynamicobjectsize(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined.

Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer.

Found by kernel fuzz testing through Xiaomi Smartphone.(CVE-2026-46088)

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

netfilter: reject zero shift in nft_bitwise

Reject zero shift operands for nft_bitwise left and right shift expressions during initialization.

The carry propagation logic computes the carry from the adjacent 32-bit word using BITSPERTYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour.

Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.(CVE-2026-46101)

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

net: strparser: fix skbhead leak in strpabort_strp()

When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head.

That skb is not released in strpabortstrp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory.

Fix this by freeing strp->skbhead and resetting the parser state in the abort path. Leave strpstop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.(CVE-2026-46102)

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

dm-thin: fix metadata refcount underflow

There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count.

If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors.

Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.(CVE-2026-46107)

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

xfrm: defensively unhash xfrm_state lists in __xfrmstatedelete

KASAN reproduces a slab-use-after-free in _xfrmstatedelete()'s hlistdelrcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrmstate lifecycle, the load-bearing one being:

BUG: KASAN: slab-use-after-free in __hlistdel include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlistdel_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in _xfrmstatedelete net/xfrm/xfrmstate.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435

Workqueue: netns cleanup_net Call Trace: __hlistdel / hlistdel_rcu _xfrmstatedelete xfrmstatedelete xfrmstateflush xfrmstatefini opsexitlist cleanupnet

The other observed signatures hit the same slab object from __xfrmstatelookup, xfrmallocspi, __xfrmstateinsert and an OOB write variant of __xfrmstatedelete, all on the byseq/byspi hash chains.

__xfrmstatedelete() guards its byseq and byspi unhashes with value-based predicates:

if (x->km.seq)
    hlist_del_rcu(&x->byseq);
if (x->id.spi)
    hlist_del_rcu(&x->byspi);

while everywhere else in the file (e.g. statecache, statecacheinput) the safer hlistunhashed() check is used. xfrmallocspi() sets x->id.spi = newspi inside xfrmstatelock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrmstatelock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second _xfrmstatedelete() on the same object writes through LISTPOISON pprev.

The defensive change here:

• Use hlistdelinitrcu() instead of hlistdelrcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LISTPOISON pprev. The byseq/byspi nodes are already initialised in xfrmstatealloc().
• Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields.

Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrmallocspi / Read in __xfrmstatelookup / Write in __xfrmstatedelete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrmstate UAF/OOB hits. /proc/slabinfo confirms the xfrmstate slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash.

Reproduction:

• Linux 6.12.47 x8664 + KASANGENERIC + KASAN_INLINE + KCOV
• syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db
• 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal
• 9 unique signatures collected in ~9h, all within xfrm_state lifecycle(CVE-2026-46116)

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

net: rtnetlink: zero iflavfbroadcast to avoid stack infoleak in rtnlfillvfinfo

rtnlfillvfinfo() declares struct iflavfbroadcast on the stack without initialisation:

struct ifla_vf_broadcast vf_broadcast;

The struct contains a single fixed 32-byte field:

/* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast {
    __u8 broadcast[32];
};

The function then copies dev->broadcast into it using dev->addr_len as the length:

memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);

On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via:

nla_put(skb, IFLA_VF_BROADCAST,
    sizeof(vf_broadcast), &vf_broadcast)

leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable.

The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vfvlaninfo, nodeguid and portguid a few lines above. vf_broadcast was simply missed when it was added.

Reachability: any unprivileged local process can open AFNETLINK / NETLINKROUTE without capabilities and send RTMGETLINK with an IFLAEXTMASK attribute carrying RTEXTFILTERVF. The kernel walks each VF and emits IFLAVFBROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nlaput() when reproduced.

Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.(CVE-2026-46132)

In the Linux kernel, xfrm6rcvencap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6routeinputlookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries.(CVE-2026-46172)

In the Linux kernel, the mlx4ibcreatesrq() function fails to release resources allocated by mlx4srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)

In the Linux kernel, the ua101 driver has a division by zero vulnerability at probe. The detectusbformat() function lacks a sanity check for the bNrChannels field. When a malicious USB audio device provides bNrChannels=0, framebytes becomes zero and is later used as a divisor in playbackurbcomplete() and captureurb_complete(), causing a kernel crash. USB core does not validate class-specific descriptor fields, so drivers must verify them before use.(CVE-2026-46184)

In the Linux kernel, drmgemfbinitwithfuncs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffercheck() uses DIVROUNDUP via drmformatinfoplanewidth/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)

['This has been assigned CVE-2026-46243, see', 'On Thursday, May 28th, 2026 at 12:07 AM, manizada <manizada () pm me> wrote:', 'Hi folks,\n\nEmailing here now that the embargo agreed upon with linux-distros@ has expired.\n\nFlagging a local root vulnerability spanning both CIFS in the kernel and\ncifs-utils in userspace (originally reported to kernel/cifs maintainers on May 16).\nThe kernel-side (only) fix has now been public for over a week and is queued for stable:\n\n3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions")\n\nImpact:\n Unprivileged user -> root code exec on any system where:\n - cifs-utils is installed (with the default cifs.spnego rule)\n - CIFS kernel module is loadable/compiled-in (typically the case), and\n - unprivileged user/mount namespaces are enabled.\n\nSome default AppArmor/SELinux profiles block this.\n\nBug:\n An unprivileged user can call requestkey("cifs.spnego", ...) with a forged\n CIFS SPNEGO description. The request-key rule starts cifs.upcall as root.\n cifs.upcall then trusts attacker-supplied pid, uid, creduid, and\n upcalltarget fields as if they came from kernel CIFS.\n\n For upcalltarget=app, affected cifs-utils versions switch into the supplied\n process&apos;s namespaces and perform NSS lookup before final privilege drop.\n A private mount namespace containing attacker-controlled /etc/nsswitch.conf\n and libnss*.so.2 is therefore sufficient for code execution in the root\n helper.\n\nAffected distros:\n This a non-exhaustive summary of some tested distros. The full table, including\n the cases where stock policy blocks exploitation (but relaxing AppArmor/SELinux/etc.\n enables exploitation), is in the attachment (and in an easier-to-read format in\n the writeup linked below).\n\n Stock-default exploitable distros\n (cifs-utils comes preinstalled in the profile + unprivileged namespaces permitted by default\n + the AA/SELinux policies, if any, do not block the attack):\n\n - Linux Mint Cinnamon 21.3 and 22.3\n - CentOS Stream 9 GNOME\n - Rocky Linux 9 Workstation\n - Kali Linux headless 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1\n - AlmaLinux 9.7 Workstation/Azure cloud image\n - SLES 15 SP7/SAP 15 SP7/SAP 16\n\n Exploitable if cifs-utils is installed, with no other default config changes:\n - Ubuntu 18.04/20.04/22.04 Desktop/Server\n - Pop!_OS 22.04 Intel/24.04 Generic\n - Ubuntu 24.04 Desktop minimal/full and Server\n - Debian 11/12/13 netinst standard and GNOME/KDE/standard/XFCE\n - CentOS Stream 9 Cinnamon/KDE/MATE/XFCE\n - Rocky Linux 9 KDE/Workstation-Lite\n - openSUSE Leap 15.6 GNOME/KDE\n - openSUSE Tumbleweed GNOME/KDE\n - Rocky Linux 8 GenericCloud\n - Oracle Linux 8/9 KVM\n - Amazon Linux 2023 KVM\n\nImmediate-term mitigations (aside from backporting the kernel fix):\n - Blocking the CIFS module from loading (assuming it&apos;s not built-in)/uninstalling cifs-utils if not used\n - Deleting/overriding the default cifs.spnego request-key rule (if Kerberos cifs is not required),\n e.g., after adjusting for your keyctl path:\n\n cat >/etc/request-key.d/cifs.spnego.conf <<&apos;EOF&apos;\n create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S\n EOF\n\n - Disabling unprivileged user namespaces\n\nThe CVE # assignment is still pending.\n\nFull writeup:', 'PoC to validate mitigations:', 'Thanks,\n-Asim Manizada'](CVE-2026-46243)

In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, _currentthreadinfo is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocatekernel(), leading to an early crash in initidle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 initidle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 initidle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<ffffffff81afada8>] initidle+0x130/0x270 [ 0.000000] [<ffffffff81afb6c0>] schedinit+0x5c8/0x6c0 [ 0.000000] [<ffffffff81ae86dc>] startkernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available. The Linux kernel CVE team has assigned CVE-2026-46250 to this issue.(CVE-2026-46250)

In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistentramsaveold() persistentramsaveold() can be called multiple times for the same persistentramzone (e.g., via ramoopspstoreread -> ramoopsgetnextprz for PSTORETYPEDMESG records). Currently, the function only allocates prz->oldlog when it is NULL, but it unconditionally updates prz->oldlogsize to the current buffer size and then performs memcpyfromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpyfromio() calls 2. A subsequent OOB read when ramoopspstoreread() accesses the buffer using the incorrect (larger) oldlogsize The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoopspstoreread+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstoregetrecords(0) reads old crash, allocates oldlog with size X 2. Crash handler registered, timer started (if pstoreupdatems >= 0) 3. Oops happens (non-fatal, system continues) 4. pstoredump() writes oops via ramoopspstorewrite() size Y (>X) 5. pstorenewentry = 1, pstoretimerkick() called 6. System continues running (not a panic oops) 7. Timer fires after pstoreupdatems milliseconds 8. pstoretimefunc() → schedulework() → pstoredowork() → pstoregetrecords(1) 9. ramoopsgetnextprz() → persistentramsaveold() 10. buffersize() returns Y, but oldlog is X bytes 11. Y > X: memcpyfromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstoreupdatems >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. The Linux kernel CVE team has assigned CVE-2026-46253 to this issue.(CVE-2026-46253)

In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading realparent in dotaskstat() When reading /proc/[pid]/stat, dotaskstat() accesses task->realparent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- dotaskstat var = task->realparent releasetask callrcu(delayedputtaskstruct) tasktgidnrns(var) rcureadlock <--- Too late to protect task->realparent! taskpidptr <--- UAF! rcureadunlock This patch uses taskppidnrns() instead of tasktgidnrns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix WQMEMRECLAIM warning When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQMEMRECLAIM xprtiod:xprtrdmaconnectworker [rpcrdma] is flushing !WQMEMRECLAIM hnsroceirqworkq:flushworkhandle [hnsrocehwv2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 checkflushdependency+0xe0/0x144 Call trace: checkflushdependency+0xe0/0x144 startflush_work.constprop.0+0x1d0/0x2f0 __flushwork.isra.0+0x40/0xb0 flushwork+0x14/0x30 hnsrocev2destroyqp+0xac/0x1e0 [hnsrocehwv2] ibdestroyqpuser+0x9c/0x2b4 rdmadestroyqp+0x34/0xb0 rpcrdmaepdestroy+0x28/0xcc [rpcrdma] rpcrdmaepput+0x74/0xb4 [rpcrdma] rpcrdmaxprtdisconnect+0x1d8/0x260 [rpcrdma] xprtrdmaconnectworker+0xc0/0x120 [rpcrdma] processonework+0x1cc/0x4d0 workerthread+0x154/0x414 kthread+0x104/0x144 retfromfork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQMEMRECLAIM. The Linux kernel CVE team has assigned CVE-2026-46265 to this issue.(CVE-2026-46265)