OESA-2026-2581

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.

This issue was detected in a situation where mvpp2_set_rx_mode() ran concurrently on two CPUs. In this particular case the MVPP2PEMACUCPROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the rx_classifier_drops counter.(CVE-2025-22060)

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

mptcp: fix NULL pointer in canacceptnew_subflow

When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcpcanacceptnewsubflow' because subflow_req->msk is NULL.

Call trace:

mptcpcanacceptnewsubflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflowsynrecvsock (./net/mptcp/subflow.c:854) tcpcheckreq (./net/ipv4/tcpminisocks.c:863) tcpv4rcv (./net/ipv4/tcpipv4.c:2268) ipprotocoldeliverrcu (./net/ipv4/ipinput.c:207) iplocaldeliverfinish (./net/ipv4/ipinput.c:234) iplocaldeliver (./net/ipv4/ipinput.c:254) iprcvfinish (./net/ipv4/ip_input.c:449) ...

According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons.

Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here.

This patch fixes this issue by moving the 'subflow_req->msk' under the own_req == true conditional.

Note that the !msk check in subflowhmacvalid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to.(CVE-2025-23145)

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

mISDN: hfcpci: Fix warning when deleting uninitialized timer

With CONFIGDEBUGOBJECTS_TIMERS unloading hfcpci module leads to the following splat:

[ 250.215892] ODEBUG: assertinit not available (active state 0) object: ffffffffc01a3dc0 object type: timerlist hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debugprintobject+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDNcore [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debugprintobject+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? traceirqenable.constprop.0+0xd4/0x130 [ 250.237920] debugobjectassertinit+0x1f6/0x310 [ 250.238762] ? __pfxdebugobjectassertinit+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __trytolock_acquire+0xdea/0x1c70 [ 250.240369] __trytodeltimersync+0x69/0x140 [ 250.241172] ? pfxrytodeltimersync+0x10/0x10 [ 250.242058] ? __timerdeletesync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timerdeletesync+0xc6/0x120 [ 250.244262] __timerdeletesync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] _dosystimerdeletesync+0xc6/0x120 [ 250.244262] __timerdeletesync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] _dosysdeletemodule+0x348/0x510 [ 250.246461] ? pfxosysdeletemodule+0x10/0x10 [ 250.247338] dosyscall64+0xc1/0x360 [ 250.247924] entrySYSCALL64afterhwframe+0x77/0x7f

Fix this by initializing hfctl timer with DEFINETIMER macro. Also, use mod_timer instead of manual timeout update.(CVE-2025-39833)

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

platform/x86/amd/pmc: Add support for Van Gogh SoC

The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix suspend.

Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver to crash while trying to resume afterwards due to a power hang.(CVE-2025-68334)

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

team: Move team device type change at the end of teamportadd

Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops.

In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that headerops->create of team0 is changed from ethheader to ipgreheader in the call to teamdevtypecheck_change.

Later when we end up in ipgreheader() struct iptunnel* points to nonsense as the private data of the device still holds a struct team.

Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1

Move teamdevtypecheckchange down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.

Also make sure to preserve the origial mtu assignment: - If portdev is not the same type as dev, dev takes mtu from portdev - If portdev is the same type as dev, portdev takes mtu from dev

This is done by adding a conditional before the call to devsetmtu to prevent it from assigning portdev->mtu = dev->mtu and instead letting teamdevtypecheckchange assign dev->mtu = portdev->mtu. The conditional is needed because the patch moves the call to teamdevtypecheckchange past devsetmtu.

Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot(CVE-2025-68340)

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

net: usb: asix: validate PHY address before use

The ASIX driver reads the PHY address from the USB device via asixreadphyaddr(). A malicious or faulty device can return an invalid address (>= PHYMAXADDR), which causes a warning in mdiobusget_phy():

addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76

Validate the PHY address in asixreadphy_addr() and remove the now-redundant check in ax88172a.c.(CVE-2025-71094)

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

ip6gre: make ip6greheader() robust

Over the years, syzbot found many ways to crash the kernel in ip6gre_header() [1].

This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheader_len

In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ip6gre device.

[1] skbuff: skbunderpanic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ip6greheader+0xc8/0x790 net/ipv6/ip6gre.c:1371 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 neighoutput include/net/neighbour.h:556 [inline] ip6finishoutput2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6finishoutput net/ipv6/ip6output.c:-1 [inline] ip6finishoutput+0x234/0x7d0 net/ipv6/ip6output.c:220 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693(CVE-2025-71098)

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

net: hns3: add VLAN id validation before using

Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlandelfailbmap is BITSTOLONGS(VLANNVID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLANN_VID.

Therefore, VLAN id needs to be checked to ensure it is within the range of VLANNVID.(CVE-2025-71112)

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

ext4: fix string copying in parseapplysbmountoptions()

strscpypad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostrpad()") provides additional information in that regard. So if this happens, the following warning is observed:

strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortifyreport+0x96/0xc0 lib/stringhelpers.c:1032 Call Trace: <TASK> __fortifypanic+0x1f/0x30 lib/stringhelpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sizedstrscpy include/linux/fortify-string.h:309 [inline] parseapplysbmount_options fs/ext4/super.c:2504 [inline] __ext4fillsuper fs/ext4/super.c:5261 [inline] ext4fillsuper+0x3c35/0xad00 fs/ext4/super.c:5706 gettreebdevflags+0x387/0x620 fs/super.c:1636 vfsgettree+0x93/0x380 fs/super.c:1814 donewmount fs/namespace.c:3553 [inline] pathmount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __dosysmount fs/namespace.c:4103 [inline] __sesysmount fs/namespace.c:4080 [inline] __x64sysmount+0x280/0x300 fs/namespace.c:4080 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x64/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x76/0x7e

Since userspace is expected to provide smountopts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of smountopts, so that strscpy_pad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)

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

drm/i915/gem: Zero-initialize the eb.vma array in i915gemdo_execbuffer

Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below.

During the execution of eblookupvmas(), the eb->vma array is successively filled up with struct ebvma objects. This process includes calling ebadd_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer.

If ebaddvma() fails, eblookupvmas() returns with an error, which prompts a call to ebreleasevmas() to clean up the mess. Since eblookupvmas() might fail during processing any (possibly not first) buffer, ebreleasevmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail.

In eblookupvmas(), eb->vma[i].vma is set to NULL if either the helper function eblookupvma() or ebvalidatevma() fails. eb->vma[i+1].vma is set to NULL in case i915gemobjectuserptrsubmitinit() fails; the current one needs to be cleaned up by ebreleasevmas() at this point, so the next one is set. If ebadd_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag.

When entering eblookupvmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the ebreleasevmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure.

(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)

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

smc91x: fix broken irq-context in PREEMPT_RT

When smc91x.c is built with PREEMPTRT, the following splat occurs in FVPRevC:

[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mldifcwork [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mldifcwork [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] _dumpstack+0x28/0x48 [ 13.062710] dumpstacklvl+0x7c/0xb0 [ 13.062818] dumpstack+0x18/0x34 [ 13.062926] processscheduledworks+0x294/0x450 [ 13.063043] workerthread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] retfromfork+0x10/0x20

This happens because smcspecialtrylock() disables IRQs even on PREEMPTRT, but smcspecialunlock() does not restore IRQs on PREEMPTRT. The reason is that smcspecialunlock() calls spinunlockirqrestore(), and rcureadunlock_bh() in __devqueuexmit() cannot invoke rcureadunlock() through _localbhenableip() when current->softirqdisablecnt becomes zero.

To address this issue, replace smcspecialtrylock() with spintrylockirqsave().(CVE-2025-71132)

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

netfilter: nf_tables: avoid chain re-validation if possible

Hamza Mahfooz reports cpu soft lock-ups in nftchainvalidate():

watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nftchainvalidate+0xcb/0x110 [nftables] [..] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nftimmediatevalidate+0x36/0x50 [nftables] nftchainvalidate+0xc9/0x110 [nftables] nfttablevalidate+0x6b/0xb0 [nftables] nftablesvalidate+0x8b/0xa0 [nftables] nftablescommit+0x1df/0x1eb0 [nftables] [..]

Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation.

Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3

Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3.

This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth.

Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains.

Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.(CVE-2025-71160)

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

btrfs: fix deadlock in waitcurrenttrans() due to ignored transaction type

When waitcurrenttrans() is called during starttransaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfsblockedtranstypes[] array already defines which transaction types should wait for which transaction states, but this check was missing in waitcurrenttrans().

This can lead to a deadlock scenario involving two transactions and pending ordered extents:

1. Transaction A is in TRANSSTATECOMMIT_DOING state

2. A worker processing an ordered extent calls starttransaction() with TRANSJOIN

3. jointransaction() returns -EBUSY because Transaction A is in TRANSSTATECOMMITDOING

4. Transaction A moves to TRANSSTATEUNBLOCKED and completes

5. A new Transaction B is created (TRANSSTATERUNNING)

6. The ordered extent from step 2 is added to Transaction B's pending ordered extents

7. Transaction B immediately starts commit by another task and enters TRANSSTATECOMMIT_START

8. The worker finally reaches waitcurrenttrans(), sees Transaction B in TRANSSTATECOMMIT_START (a blocked state), and waits unconditionally

9. However, TRANSJOIN should NOT wait for TRANSSTATECOMMITSTART according to btrfsblockedtrans_types[]

10. Transaction B is waiting for pending ordered extents to complete

11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B

This can be illustrated by the following call stacks: CPU0 CPU1 btrfsfinishorderedio() starttransaction(TRANSJOIN) jointransaction() # -EBUSY (Transaction A is # TRANSSTATECOMMITDOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfscommittransaction() # Transaction B enters # TRANSSTATECOMMITSTART # waiting for pending ordered # extents waitcurrenttrans() # waits for Transaction B # (should not wait!)

Task bstorekvsync in btrfscommittransaction waiting for ordered extents:

__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfscommittransaction+0xbf7/0xda0 [btrfs] btrfssyncfile+0x342/0x4d0 [btrfs] __x64sysfdatasync+0x4b/0x80 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xa9

Task kworker in waitcurrenttrans waiting for transaction commit:

Workqueue: btrfs-synonocow btrfswork_helper [btrfs] _schedule+0x2e7/0x8a0 schedule+0x64/0xe0 waitcurrenttrans+0xb0/0x110 [btrfs] starttransaction+0x346/0x5b0 [btrfs] btrfsfinishorderedio.isra.0+0x49b/0x9c0 [btrfs] btrfsworkhelper+0xe8/0x350 [btrfs] processonework+0x1d3/0x3c0 workerthread+0x4d/0x3e0 kthread+0x12d/0x150 retfromfork+0x1f/0x30

Fix this by passing the transaction type to waitcurrenttrans() and checking btrfsblockedtranstypes[curtrans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.(CVE-2025-71194)

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

iommu/sva: invalidate stale IOTLB entries for kernel address space

Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.

This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.

Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.(CVE-2025-71202)

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

audit: add fchmodat2() to change attributes class

fchmodat2(), introduced in version 6.6 is currently not in the change attribute class of audit. Calling fchmodat2() to change a file attribute in the same fashion than chmod() or fchmodat() will bypass audit rules such as:

-w /tmp/test -p rwa -k test_rwa

The current patch adds fchmodat2() to the change attributes class.(CVE-2025-71239)

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

macvlan: fix possible UAF in macvlanforwardsource()

Add RCU protection on (struct macvlansourceentry)->vlan.

Whenever macvlanhashdel_source() is called, we must clear entry->vlan pointer before RCU grace period starts.

This allows macvlanforwardsource() to skip over entries queued for freeing.

Note that macvlandev are already RCU protected, as they are embedded in a standard netdev (netdevpriv(ndev)).

https: //lore.kernel.org/netdev/(CVE-2026-23001)

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

uacce: ensure safe queue release with state management

Directly calling put_queue carries risks since it cannot guarantee that resources of uacce_queue have been fully released beforehand. So adding a stop_queue operation for the UACCECMDPUT_Q command and leaving the put_queue operation to the final resource release ensures safety.

Queue states are defined as follows: - UACCEQZOMBIE: Initial state - UACCEQINIT: After opening uacce - UACCEQSTARTED: After start is issued via ioctl

When executing poweroff -f in virt while accelerator are still working, uacce_fops_release and uacce_remove may execute concurrently. This can cause uacce_put_queue within uacce_fops_release to access a NULL ops pointer. Therefore, add state checks to prevent accessing freed pointers.(CVE-2026-23063)

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

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <(CVE-2026-23074)

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

arm64/fpsimd: signal: Fix restoration of SVE context

When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.

(1) Restoring a context with SVESIGFLAGSM set can place the task into an invalid state where SVCR.SM is set (and svestate is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.

This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM implies that
TIF_SME is already set.

While in this state, task_fpsimd_load() will NOT configure SMCR_ELx
(leaving some arbitrary value configured in hardware) before
restoring SVCR and attempting to restore the streaming mode SVE
registers from memory via sve_load_state(). As the value of
SMCR_ELx.LEN may be larger than the task's streaming SVE vector
length, this may read memory outside of the task's allocated
sve_state, reading unrelated data and/or triggering a fault.

While this can result in secrets being loaded into streaming SVE
registers, these values are never exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0
accesses to streaming mode SVE registers, so these cannot be
accessed directly at EL0. As fpsimd_save_user_state() verifies the
live vector length before saving (S)SVE state to memory, no secret
values can be saved back to memory (and hence cannot be observed via
ptrace, signals, etc).

When the live vector length doesn't match the expected vector length
for the task, fpsimd_save_user_state() will send a fatal SIGKILL
signal to the task. Hence the task may be killed after executing
userspace for some period of time.

(2) Restoring a context with SVESIGFLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.

This can only occur in unusual (but legitimate) cases where ptrace
has been used to set SVCR.SM after entry to the sigreturn syscall,
as syscall entry clears SVCR.SM.

In these cases, the the provided SVE register data will be loaded
into the task's sve_state using the non-streaming SVE vector length
and the FPSIMD registers will be merged into this using the
streaming SVE vector length.

Fix (1) by setting TIFSME when setting SVCR.SM. This also requires ensuring that the task's smestate has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVESIGFLAG_SM clear.

For consistency, I've pulled the manipulation of SVCR, TIFSVE, TIFSME, and fptype earlier, immediately after the allocation of svestate/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.(CVE-2026-23102)

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

mm/shmem, swap: fix race of truncate and swap entry split

The helper for shmem swap freeing is not handling the order of swap entries correctly. It uses xacmpxchgirq to erase the swap entry, but it gets the entry order before that using xagetorder without lock protection, and it may get an outdated order value if the entry is split or changed in other ways after the xagetorder and before the xacmpxchgirq.

And besides, the order could grow and be larger than expected, and cause truncation to erase data beyond the end border. For example, if the target entry and following entries are swapped in or freed, then a large folio was added in place and swapped out, using the same entry, the xacmpxchgirq will still succeed, it's very unlikely to happen though.

To fix that, open code the Xarray cmpxchg and put the order retrieval and value checking in the same critical section. Also, ensure the order won't exceed the end border, skip it if the entry goes across the border.

Skipping large swap entries crosses the end border is safe here. Shmem truncate iterates the range twice, in the first iteration, findlockentries already filtered such entries, and shmem will swapin the entries that cross the end border and partially truncate the folio (split the folio or at least zero part of it). So in the second loop here, if we see a swap entry that crosses the end order, it must at least have its content erased already.

I observed random swapoff hangs and kernel panics when stress testing ZSWAP with shmem. After applying this patch, all problems are gone.(CVE-2026-23161)

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

RDMA/umad: Reject negative datalen in ibumad_write

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative data_len before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumad_write+0x853/0x1c80(CVE-2026-23243)

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

nvme: fix memory allocation in nvmeprread_keys()

nvmeprreadkeys() takes numkeys from userspace and uses it to calculate the allocation size for rse via structsize(). The upper limit is PRKEYS_MAX (64K).

A malicious or buggy userspace can pass a large numkeys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAXPAGE_ORDER.

To fix this, use kvzalloc() instead of kzalloc().

This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/(CVE-2026-23244)

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

netfilter: nf_tables: unconditionally bump set->nelems before insertion

In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.

To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state.

As for element updates, decrement set->nelems to restore it.

A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.(CVE-2026-23272)

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

net: usb: kaweth: validate USB endpoints

The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23312)

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

net: sched: avoid qdiscresetalltxgt() vs dequeue race for lockless qdiscs

When shrinking the number of real tx queues, netifsetrealnumtxqueues() calls qdiscresetalltx_gt() to flush qdiscs for queues which will no longer be used.

qdiscresetalltxgt() currently serializes qdiscreset() with qdisclock(). However, for lockless qdiscs, the dequeue path is serialized by qdiscrunbegin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with _qdiscrun() and free skbs while they are still being dequeued, leading to UAF.

This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:

iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done

With KASAN enabled, this leads to reports like:

BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __devqueuexmit+0x248f/0x3550 ipfinishoutput2+0xa42/0x2110 ipoutput+0x1a7/0x410 ipsendskb+0x2e6/0x480 udpsendskb+0xb0a/0x1590 udpsendmsg+0x13c9/0x1fc0 ... </TASK>

Allocated by task 1270 on cpu 5 at 44.558414s: ... allocskbwithfrags+0x84/0x7c0 sockallocsendpskb+0x69a/0x830 _ipappenddata+0x1b86/0x48c0 ipmakeskb+0x1e8/0x2b0 udpsendmsg+0x13a6/0x1fc0 ...

Freed by task 1306 on cpu 3 at 44.558445s: ... kmemcachefree+0x117/0x5e0 pfifofastreset+0x14d/0x580 qdiscreset+0x9e/0x5f0 netifsetrealnumtxqueues+0x303/0x840 virtnetsetchannels+0x1bf/0x260 [virtionet] ethnlsetchannels+0x684/0xae0 ethnldefaultsetdoit+0x31a/0x890 ...

Serialize qdiscresetalltxgt() against the lockless dequeue path by taking qdisc->seqlock for TCQFNOLOCK qdiscs, matching the serialization model already used by devresetqueue().

Additionally clear QDISCSTATENON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)

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

net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check

cdcncmrxverifyndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset:

if ((ndpoffset + sizeof(struct usbcdcncmndp16)) > skbin->len)

but the second check omits it:

if ((sizeof(struct usbcdcncmndp16) + ret * (sizeof(struct usbcdcncmdpe16))) > skb_in->len)

This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdcncmrx_fixup() then reads out-of-bounds memory when iterating the DPE array.

Add ndpoffset to the nframes bounds check and use structsizet() to express the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)

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

smb: client: fix krb5 mount with username option

Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts.

By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos.

For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong.

$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for (CVE-2026-31392)

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

mm/rmap: fix incorrect pte restoration for lazyfree folios

We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch.  If the
batch has a mix of writable and non-writable bits, we may end up setting
the entire batch writable.  Fix this by respecting writable bit during
batching.

Although on a successful unmap of a lazyfree folio, the soft-dirty bit is
lost, preserve it on pte restoration by respecting the bit during
batching, to make the fix consistent w.r.t both writable bit and
soft-dirty bit.

I was able to write the below reproducer and crash the kernel. 
Explanation of reproducer (set 64K mTHP to always):

Fault in a 64K large folio.  Split the VMA at mid-point with
MADV_DONTFORK.  fork() - parent points to the folio with 8 writable ptes
and 8 non-writable ptes.  Merge the VMAs with MADV_DOFORK so that
folio_unmap_pte_batch() can determine all the 16 ptes as a batch.  Do
MADV_FREE on the range to mark the folio as lazyfree.  Write to the memory
to dirty the pte, eventually rmap will dirty the folio.  Then trigger
reclaim, we will hit the pte restoration path, and the kernel will crash
with the trace given below.

The BUG happens at:

    BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw);

The code path is asking for anonymous page to be mapped writable into the
pagetable.  The BUG_ON() firing implies that such a writable page has been
mapped into the pagetables of more than one process, which breaks
anonymous memory/CoW semantics.

[   21.134473] kernel BUG at mm/page_table_check.c:118!
[   21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
[   21.135917] Modules linked in:
[   21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT
[   21.136858] Hardware name: linux,dummy-virt (DT)
[   21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   21.137308] pc : page_table_check_set+0x28c/0x2a8
[   21.137607] lr : page_table_check_set+0x134/0x2a8
[   21.137885] sp : ffff80008a3b3340
[   21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000
[   21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001
[   21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30
[   21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000
[   21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff
[   21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020
[   21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0
[   21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff
[   21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002
[   21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0
[   21.141991] Call trace:
[   21.142093]  page_table_check_set+0x28c/0x2a8 (P)
[   21.142265]  __page_table_check_ptes_set+0x144/0x1e8
[   21.142441]  __set_ptes_anysz.constprop.0+0x160/0x1a8
[   21.142766]  contpte_set_ptes+0xe8/0x140
[   21.142907]  try_to_unmap_one+0x10c4/0x10d0
[   21.143177]  rmap_walk_anon+0x100/0x250
[   21.143315]  try_to_unmap+0xa0/0xc8
[   21.143441]  shrink_folio_list+0x59c/0x18a8
[   21.143759]  shrink_lruvec+0x664/0xbf0
[   21.144043]  shrink_node+0x218/0x878
[   21.144285]  __node_reclaim.constprop.0+0x98/0x338
[   21.144763]  user_proactive_reclaim+0x2a4/0x340
[   21.145056]  reclaim_store+0x3c/0x60
[   21.145216]  dev_attr_store+0x20/0x40
[   21.145585]  sysfs_kf_write+0x84/0xa8
[   21.145835]  kernfs_fop_write_iter+0x130/0x1c8
[   21.145994]  vfs_write+0x2b8/0x368
[   21.146119]  ksys_write+0x70/0x110
[   21.146240]  __arm64_sys_write+0x24/0x38
[   21.146380]  invoke_syscall+0x50/0x120
[   21.146513]  el0_svc_common.constprop.0+0x48/0xf8
[   21.146679]  do_el0_svc+0x28/0x40
[   21.146798]  el0_svc+0x34/0x110
[   21.146926]  el0t
---truncated---(CVE-2026-31398)

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

net/sched: cls_fw: fix NULL pointer dereference on shared blocks

The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle.  Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.

Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.

The fixed null-ptr-deref calling stack:
 KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
 RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
 Call Trace:
  tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
  tc_run (net/core/dev.c:4401)
  __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)

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

net/sched: cls_flow: fix NULL pointer dereference on shared blocks

flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass.  Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.

Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks.  This avoids the null-deref shown below:

=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
 tc_new_tfilter (net/sched/cls_api.c:2432)
 rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
 [...]
=======================================================================(CVE-2026-31422)

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

net: skb: fix cross-cache free of KFENCE-allocated skb head

SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
bucket sizes. This ensures that skb_kfree_head() can reliably use
skb_end_offset to distinguish skb heads allocated from
skb_small_head_cache vs. generic kmalloc caches.

However, when KFENCE is enabled, kfence_ksize() returns the exact
requested allocation size instead of the slab bucket size. If a caller
(e.g. bpf_test_init) allocates skb head data via kzalloc() and the
requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
slab_build_skb() -> ksize() returns that exact value. After subtracting
skb_shared_info overhead, skb_end_offset ends up matching
SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
the object to skb_small_head_cache instead of back to the original
kmalloc cache, resulting in a slab cross-cache free:

  kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected
  skbuff_small_head but got kmalloc-1k

Fix this by always calling kfree(head) in skb_kfree_head(). This keeps
the free path generic and avoids allocator-specific misclassification
for KFENCE objects.(CVE-2026-31429)

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

X.509: Fix out-of-bounds access when parsing extensions

Leo reports an out-of-bounds access when parsing a certificate with
empty Basic Constraints or Key Usage extension because the first byte of
the extension is read before checking its length.  Fix it.

The bug can be triggered by an unprivileged user by submitting a
specially crafted certificate to the kernel through the keyrings(7) API.
Leo has demonstrated this with a proof-of-concept program responsibly
disclosed off-list.(CVE-2026-31430)

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

dmaengine: idxd: Fix memory leak when a wq is reset

idxd_wq_disable_cleanup() which is called from the reset path for a
workqueue, sets the wq type to NONE, which for other parts of the
driver mean that the wq is empty (all its resources were released).

Only set the wq type to NONE after its resources are released.(CVE-2026-31441)

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

dmaengine: idxd: Fix possible invalid memory access after FLR

In the case that the first Function Level Reset (FLR) concludes
correctly, but in the second FLR the scratch area for the saved
configuration cannot be allocated, it's possible for a invalid memory
access to happen.

Always set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)

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

ext4: fix use-after-free in update_super_work when racing with umount

Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():

  update_super_work                ext4_put_super
  -----------------                --------------
                                   ext4_unregister_sysfs(sb)
                                     kobject_del(&sbi->s_kobj)
                                       __kobject_del()
                                         sysfs_remove_dir()
                                           kobj->sd = NULL
                                         sysfs_put(sd)
                                           kernfs_put()  // RCU free
  ext4_notify_error_sysfs(sbi)
    sysfs_notify(&sbi->s_kobj)
      kn = kobj->sd              // stale pointer
      kernfs_get(kn)             // UAF on freed kernfs_node
                                   ext4_journal_destroy()
                                     flush_work(&sbi->s_sb_upd_work)

Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)

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

ext4: validate p_idx bounds in ext4_ext_correct_indexes

ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the first extent in a leaf is modified. Before
accessing path[k].p_idx->ei_block, there is no validation that
p_idx falls within the valid range of index entries for that
level.

If the on-disk extent header contains a corrupted or crafted
eh_entries value, p_idx can point past the end of the allocated
buffer, causing a slab-out-of-bounds read.

Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at
both access sites: before the while loop and inside it. Return
-EFSCORRUPTED if the index pointer is out of range, consistent
with how other bounds violations are handled in the ext4 extent
tree code.(CVE-2026-31449)

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

ext4: publish jinode after initialization

ext4_inode_attach_jinode() publishes ei->jinode to concurrent users.
It used to set ei->jinode before jbd2_journal_init_jbd_inode(),
allowing a reader to observe a non-NULL jinode with i_vfs_inode
still unset.

The fast commit flush path can then pass this jinode to
jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and
may crash.

Below is the crash I observe:

BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fcfsyncbench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xasfindmarked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> filemapgetfolios_tag+0x87/0x2a0 __filemapfdatawaitrange+0x5f/0xd0 ? srsoaliasreturn_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 ? capsafenice+0x37/0x70 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 filemapfdatawaitrangekeeperrors+0x12/0x40 ext4fccommit+0x697/0x8b0 ? ext4filewriteiter+0x64b/0x950 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 ? vfswrite+0x356/0x480 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ext4syncfile+0xf7/0x370 dofsync+0x3b/0x80 ? syscalltraceenter+0x108/0x1d0 __x64sysfdatasync+0x16/0x20 dosyscall64+0x62/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e ... ```

Fix this by initializing the jbd2inode first. Use smpwmb() and WRITEONCE() to publish ei->jinode after initialization. Readers use READONCE() to fetch the pointer.(CVE-2026-31450)

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

ext4: replace BUGON with proper error handling in ext4readinlinefolio

Replace BUGON() with proper error handling when inline data size exceeds PAGESIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption.

The error is logged via ext4errorinode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.(CVE-2026-31451)

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

ext4: convert inline data to extents when truncate exceeds inline size

Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline.

Without this fix, the following sequence causes a kernel BUG_ON():

1. Mount filesystem with inode that has inline flag set and small size
2. truncate(file, 50MB) - grows size but inline flag remains set
3. sendfile() attempts to write data
4. ext4writeinlinedata() hits BUGON(writesize > inlinecapacity)

The crash occurs because ext4writeinlinedata() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for iblock + ~96 bytes for xattrs) is far smaller than the file size and write request.

The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4I(inode)->iinline_size) and converts the file to extent-based storage before proceeding with the size change.

This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.(CVE-2026-31452)

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

erofs: add GFP_NOIO in the bio completion if needed

The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vmmapram() with GFP_KERNEL.

Due to insufficient memory, vmmapram() may generate memory swapping I/O, which can cause submitbiowait to deadlock in some scenarios.

Trimmed down the call stack, as follows:

f2fssubmitreadio submitbio //biolist is initialized. mmcblkmqrecovery zerofsendio vmmapram __pteallockernel __allocpagesdirectreclaim shrinkfolio_list __swapwritepage submitbiowait //biolist is non-NULL, hang!!!

Use memallocnoio{save,restore}() to wrap up this path.(CVE-2026-31467)

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

virtionet: Fix UAF on dstops when IFFXMITDSTRELEASE is cleared and napitx is false

A UAF issue occurs when the virtionet driver is configured with napitx=N and the device's IFFXMITDST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules).

When IFFXMITDSTRELEASE is removed from the netdevice, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtionet with napitx=N, skbs may remain in the virtio transmit ring for an extended period.

If the network namespace is destroyed while these skbs are still pending, the corresponding dstops structure has freed. When a subsequent packet is transmitted, freeoldxmit() is triggered to clean up old skbs. It then calls dstrelease() on the skb associated with the stale dstentry. Since the dstops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs.

fix it by adds skbdstdrop(skb) in startxmit to explicitly release the dst reference before the skb is queued in virtionet.

Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpucounteraddbatch+0x3c/0x158 lib/percpucounter.c:98 (P) dstrelease+0xe0/0x110 net/core/dst.c:177 skbreleaseheadstate+0xe8/0x108 net/core/skbuff.c:1177 skskbreasondrop+0x54/0x2d8 net/core/skbuff.c:1255 devkfreeskbanyreason+0x64/0x78 net/core/dev.c:3469 napiconsume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 _freeoldxmit+0x164/0x230 drivers/net/virtionet.c:611 [virtionet] freeoldxmit drivers/net/virtionet.c:1081 [virtionet] startxmit+0x7c/0x530 drivers/net/virtionet.c:3329 [virtionet] ...

Reproduction Steps: NETDEV="enp3s0"

configqdiscroute_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 }

test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns }

configqdiscroute_filter

testns sleep 2 testns(CVE-2026-31469)

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

spi: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. [1]

Also note that we do not enable the driveroverride feature of struct bustype, as SPI - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".(CVE-2026-31487)

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

netfilter: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

• CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check.
• CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.
• CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERF_ALL, removing the manual mask checks.
• CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECT_MASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.(CVE-2026-31495)

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

netfilter: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").(CVE-2026-31496)

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

Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop

l2capconfigreq() processes CONFIGREQ for channels in BTCONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONFINPUTDONE and CONFOUTPUTDONE are already set from the initial configuration, the reconfiguration path falls through to l2capertminit(), which re-initializes txq, srejq, srejlist, and retranslist without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources.

Additionally, l2capparseconfreq() does not validate the minimum value of remotemps derived from the RFC maxpdusize option. A zero value propagates to l2capsegmentsdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory.

Fix the double-init by skipping l2capertminit() and l2capchanready() when the channel is already in BTCONNECTED state, while still allowing the reconfiguration parameters to be updated through l2capparseconfreq(). Also add a pdulen zero check in l2capsegment_sdu() as a safeguard.(CVE-2026-31498)

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

Bluetooth: L2CAP: Fix deadlock in l2capconndel()

l2capconndel() calls canceldelayedworksync() for both infotimer and idaddrtimer while holding conn->lock. However, the work functions l2capinfotimeout() and l2capconnupdateidaddr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2capconndel() takes the lock.

Move the work cancellations before acquiring conn->lock and use disabledelayedworksync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hciconn_del().(CVE-2026-31499)

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

iavf: fix out-of-bounds writes in iavfgetethtool_stats()

iavf incorrectly uses realnumtxqueues for ETHSSSTATS. Since the value could change in runtime, we should use numtx_queues instead.

Moreover iavfgetethtoolstats() uses numactivequeues while iavfgetssetcount() and iavfgetstatstrings() use realnumtxqueues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].

For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:

Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavfsetchannels() ... iavfallocqueues() -> numactivequeues = 8 iavfschedulefinishconfig() iavfgetssetcount() realnumtxqueues: 1 -> buffer for 1 queue iavfgetethtoolstats() numactivequeues: 8 -> out-of-bounds! iavffinishconfig() -> realnumtx_queues = 8

Use immutable numtxqueues in all related functions to avoid the issue.

[1] BUG: KASAN: vmalloc-out-of-bounds in iavfaddoneethtoolstat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800

CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x180 iavfaddoneethtoolstat+0x200/0x270 iavfgetethtool_stats+0x14c/0x2e0 __devethtool+0x3d0c/0x5830 devethtool+0x12d/0x270 devioctl+0x53c/0xe30 sockdoioctl+0x1a9/0x270 sockioctl+0x3d4/0x5e0 __x64sysioctl+0x137/0x1c0 dosyscall64+0xf3/0x690 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>

The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at _devethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)

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

Bluetooth: L2CAP: Fix null-ptr-deref on l2capsockready_cb

Before using sk pointer, check if it is null.

Fix the following:

KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2capinfotimeout RIP: 0010:kasanbyteaccessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> __kasancheckbyte+0x12/0x40 lockacquire+0x79/0x2e0 locksocknested+0x48/0x100 ? l2capsockreadycb+0x46/0x160 l2capsockreadycb+0x46/0x160 l2capconn_start+0x779/0xff0 ? __pfxl2capconnstart+0x10/0x10 ? l2capinfotimeout+0x60/0xa0 ? pfxmutexlock+0x10/0x10 l2capinfotimeout+0x68/0xa0 ? processscheduledworks+0xa8d/0x18c0 processscheduled_works+0xb6e/0x18c0 ? __pfxprocessscheduledworks+0x10/0x10 ? assignwork+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfxworkerthread+0x10/0x10 ? __pfxkthread+0x10/0x10 retfrom_fork+0x51e/0xb90 ? __pfxretfromfork+0x10/0x10 veth1macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- batmanadv: batadv0: Interface activated: batadvslave0 batmanadv: batadv0: Interface activated: batadvslave1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasanbyteaccessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrelht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception(CVE-2026-31510)

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

Bluetooth: MGMT: Fix dangling pointer on mgmtaddadvpatternsmonitor_complete

This fixes the condition checking so mgmtpendingvalid is executed whenever status != -ECANCELED otherwise calling mgmtpendingfree(cmd) would kfree(cmd) without unlinking it from the list first, leaving a dangling pointer. Any subsequent list traversal (e.g., mgmtpendingforeach during __mgmtpoweroff, or another mgmtpendingvalid call) would dereference freed memory.(CVE-2026-31511)

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

Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2capecreddata_rcv()

l2capecreddatarcv() reads the SDU length field from skb->data using getunalignedle16() without first verifying that skb contains at least L2CAPSDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb.

The ERTM reassembly path correctly calls pskbmaypull() before reading the SDU length (l2capreassemblesdu, L2CAPSARSTART case). Apply the same validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)

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

xfrm: prevent policy_hthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhash_rebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policy_hthresh.work.

Synchronize policyhthresh.work in xfrmpolicy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.(CVE-2026-31516)

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

esp: fix skb leak with espintcp and async crypto

When the TX queue for espintcp is full, espoutputtail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us.

With async crypto (espoutputdone), we need to drop the skb when espoutputtail_tcp returns an error.(CVE-2026-31518)

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

bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN

The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result.

The verifier's abstract interpretation (scalar32minmax_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access.

Introduce abss32() which handles S32MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.

s32 is the only affected case -- the s64 division/modulo handlers do not use abs().(CVE-2026-31525)

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

perf: Make sure to use pmu_ctx->pmu for groups

Oliver reported that x86pmudel() ended up doing an out-of-bound memory access when groupschedin() fails and needs to roll back.

This should be handled by the transaction callbacks, but he found that when the group leader is a software event, the transaction handlers of the wrong PMU are used. Despite the movegroup case in perfeventopen() and groupschedin() using pmuctx->pmu.

Turns out, inherit uses event->pmu to clone the events, effectively undoing the movegroup case for all inherited contexts. Fix this by also making inherit use pmuctx->pmu, ensuring all inherited counters end up in the same pmu context.

Similarly, _perfeventread() should use equally use pmuctx->pmu for the group case.(CVE-2026-31528)

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

can: raw: fix ro->uniq use-after-free in raw_rcv()

rawrelease() unregisters raw CAN receive filters via canrxunregister(), but receiver deletion is deferred with callrcu(). This leaves a window where rawrcv() may still be running in an RCU read-side critical section after rawrelease() frees ro->uniq, leading to a use-after-free of the percpu uniq storage.

Move freepercpu(ro->uniq) out of rawrelease() and into a raw-specific socket destructor. canrxunregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained.

mkl: applied manually

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

net/tls: fix use-after-free in -EBUSY error path of tlsdoencryption

The -EBUSY handling in tlsdoencryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry.

When cryptoaeadencrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tlsencryptdone() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encryptpending. However, if tlsencryptasyncwait() returns an error, the synchronous error path in tlsdoencryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist.

The double-decrement corrupts the encryptpending sentinel (initialized to 1), making tlsencryptasyncwait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tlsrec via bpfexectxverdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.

Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.(CVE-2026-31533)

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

drm/i915/gt: Check setdefaultsubmission() before deferencing

When the i915 driver firmware binaries are not present, the setdefaultsubmission pointer is not set. This pointer is dereferenced during suspend anyways.

Add a check to make sure it is set before dereferencing.

[ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: errorcode(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPUOUTOFSPEC, [W]=WARN [ 23.496511] Workqueue: async asyncrunentryfn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] <TASK> [ 23.579905] intelenginesresetdefault_submission+0x42/0x60 [ 23.585695] __intelgtunsetwedged+0x191/0x200 [ 23.590360] intelgtunsetwedged+0x20/0x40 [ 23.594675] gtsanitize+0x15e/0x170 [ 23.598290] i915gemsuspendlate+0x6b/0x180 [ 23.602692] i915drmsuspend_late+0x35/0xf0 [ 23.607008] ? __pfxpcipmsuspendlate+0x10/0x10 [ 23.611843] dpmruncallback+0x78/0x1c0 [ 23.615817] devicesuspendlate+0xde/0x2e0 [ 23.620037] asyncsuspendlate+0x18/0x30 [ 23.624082] asyncrunentryfn+0x25/0xa0 [ 23.628129] processonework+0x15b/0x380 [ 23.632182] workerthread+0x2a5/0x3c0 [ 23.635973] ? __pfxworkerthread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfxkthread+0x10/0x10 [ 23.651045] retfrom_fork+0x131/0x190 [ 23.654837] ? __pfxkthread+0x10/0x10 [ 23.658634] retfromforkasm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------

(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)

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

x86/platform/uv: Handle deconfigured sockets

When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures.

Fix this by using NUMANONODE, allowing UV hub info structures to be allocated on valid nodes.(CVE-2026-31542)

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

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bond_alb.c already handle this NULL-slave state safely:

• rlbupdateclient returns early on !client_info->slave
• rlbrequpdateslaveclients, rlbclearslave, and rlb_rebalance compare slave values before visiting
• lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.(CVE-2026-31546)

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

futex: Clear stale exiting pointer in futexlockpi() retry path

Fuzzying/stressing futexes triggered:

WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524

When futexlockpi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'.

After waitforownerexiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futexlockpiatomic() returns a different error, the bogus pointer is passed to waitforowner_exiting().

CPU0 CPU1 CPU2 futexlockpi(uaddr) // acquires the PI futex exit() futexcleanupbegin() futexstate = EXITING; futexlockpi(uaddr) futexlockpiatomic() attachtopiowner() // observes EXITING *exiting = owner; // takes ref return -EBUSY waitforownerexiting(-EBUSY, owner) puttaskstruct(); // drops ref // exiting still points to owner goto retry; futexlockpiatomic() lockpiupdateatomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; waitforownerexiting(-EAGAIN, exiting) // stale WARNON_ONCE(exiting)

Fix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)

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

drm/amdgpu: Fix fence put before wait in amdgpuamdkfdsubmit_ib

amdgpuamdkfdsubmitib() submits a GPU job and gets a fence from amdgpuib_schedule(). This fence is used to wait for job completion.

Currently, the code drops the fence reference using dmafenceput() before calling dmafencewait().

If dmafenceput() releases the last reference, the fence may be freed before dmafencewait() is called. This can lead to a use-after-free.

Fix this by waiting on the fence first and releasing the reference only after dmafencewait() completes.

Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpuamdkfd.c:697 amdgpuamdkfdsubmitib() warn: passing freed memory 'f' (line 696)

(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)

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

can: gw: fix OOB heap access in cgwcsumcrc8_rel()

cgwcsumcrc8rel() correctly computes bounds-safe indices via calcidx():

int from = calc_idx(crc8->from_idx, cf->len);
int to   = calc_idx(crc8->to_idx,   cf->len);
int res  = calc_idx(crc8->result_idx, cf->len);

if (from < 0 || to < 0 || res < 0)
    return;

However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:

for (i = crc8->from_idx; ...)        /* BUG: raw negative index */
cf->data[crc8->result_idx] = ...;    /* BUG: raw negative index */

With fromidx = toidx = resultidx = -64 on a 64-byte CAN FD frame, calcidx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap.

The companion function cgwcsumxorrel() uses from/to/res correctly throughout; fix cgwcsumcrc8rel() to match.

Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgwcsumcrc8rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poccgw_oob/62

To configure the can-gw crc8 checksums CAPNETADMIN is needed.(CVE-2026-31570)

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

KVM: SEV: Drop WARN on large size for KVMMEMORYENCRYPTREGREGION

Drop the WARN in sevpinmemory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing:

struct kvmencregion range = { .addr = 0, .size = -1ul, };

_vmioctl(vm, KVMMEMORYENCRYPTREGREGION, &range);

Note, the checks in sevmemencregisterregion() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they can't be greater than ULONG_MAX. That wart will be cleaned up in the near future.

if (range->addr > ULONG_MAX || range->size > ULONG_MAX)
    return -EINVAL;

Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)

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

PCI: endpoint: pci-epf-vntb: Stop cmdhandler work in epfntbepccleanup

Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.

Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epfntbcmdhandler+0x54/0x200 [pciepfvntb] (P) processonework+0x154/0x3b0 workerthread+0x2c8/0x400 kthread+0x148/0x210 retfromfork+0x10/0x20(CVE-2026-31595)

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

x86/CPU: Fix FPDSS on Zen1

Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread.

Fix that with a chicken bit.(CVE-2026-31628)

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

rxrpc: proc: size address buffers for %pISpc output

The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6addris_isatap().

As a result, a case such as

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example(CVE-2026-31630)

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

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.(CVE-2026-31651)

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

netfilter: nft_ct: fix use-after-free in timeout object destroy

nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().

Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c.

KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80

Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhook_slow+0x70/0x100 __iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 _syssendto+0x2d8/0x320

Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00

Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0(CVE-2026-31665)

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

Input: uinput - fix circular locking dependency with ff-core

A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):

ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex

The cycle is caused by four lock acquisition paths:

1. ff upload: inputffupload() holds ff->mutex and calls uinputdevuploadeffect() -> uinputrequestsubmit() -> uinputrequest_send(), which acquires udev->mutex.

2. device create: uinputioctlhandler() holds udev->mutex and calls uinputcreatedevice() -> inputregisterdevice(), which acquires input_mutex.

3. device register: inputregisterdevice() holds inputmutex and calls kbdconnect() -> inputregisterhandle(), which acquires dev->mutex.

4. evdev release: evdevrelease() calls inputflushdevice() under dev->mutex, which calls inputff_flush() acquiring ff->mutex.

Fix this by introducing a new statelock spinlock to protect udev->state and udev->dev access in uinputrequestsend() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinputdevevent() -- both operations are safe under a spinlock (ktimegetts64() and wakeup_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.

To keep state transitions visible to uinputrequestsend(), protect writes to udev->state in uinputcreatedevice() and uinputdestroydevice() with the same state_lock spinlock.

Additionally, move initcompletion(&request->done) from uinputrequestsend() to uinputrequestsubmit() before uinputrequestreserveslot(). Once the slot is allocated, uinputflushrequests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.

Lock ordering after the fix:

ff->mutex -> statelock (spinlock, leaf) udev->mutex -> statelock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)(CVE-2026-31667)

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

net/sched: sch_netem: fix out-of-bounds access in packet corruption

In netemenqueue(), the packet corruption logic uses getrandomu32below(skbheadlen(skb)) to select an index for modifying skb->data. When an AFPACKET TXRING sends fully non-linear packets over an IPIP tunnel, skbheadlen(skb) evaluates to 0.

Passing 0 to getrandomu32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access.

Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.(CVE-2026-31675)

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

crypto: af_alg - limit RX SG extraction by receive buffer budget

Make afalgget_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.

afalggetrsgl() currently uses afalgreadable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining afalg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.

If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.(CVE-2026-31677)

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

openvswitch: defer tunnel netdev_put to RCU release

ovsnetdevtunneldestroy() may run after NETDEVUNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.

Do not release vport->dev in ovsnetdevtunneldestroy(). Instead, let vportnetdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.(CVE-2026-31678)

In the Linux kernel, a memory out-of-bounds access vulnerability exists in the actcsum module's tcfcsumact() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb->data. The current code reads vlan->hvlanencapsulatedproto and then pulls VLANHLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing hvlanencapsulatedproto reads past the linear area, and the following skbpull(VLANHLEN) may violate skb invariants.(CVE-2026-31684)

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

netfilter: ip6t_eui64: reject invalid MAC header for all packets

eui64_mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.

The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64_mt6() can still reach eth_hdr(skb) even when the MAC header is not valid.

Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing eth_hdr(skb).(CVE-2026-31685)

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

EDAC/mc: Fix error path ordering in edacmcalloc()

When the mci->pvtinfo allocation in edacmcalloc() fails, the error path will call putdevice() which will end up calling the device's release function.

However, the init ordering is wrong such that device_initialize() happens after the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called:

MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobjectput() is being called. WARNING: lib/kobject.c:734 at kobjectput, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobjectput Call Trace: <TASK> edacmcalloc+0xbe/0xe0 [edaccore] amd64edacinit+0x7a4/0xff0 [amd64_edac] ? __pfxamd64edacinit+0x10/0x10 [amd64edac] dooneinitcall ...

Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used.

This was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)

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

crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed

When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388

CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldogetid2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sevioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31697)

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

crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed

When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033

CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopdhexport+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sevioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)

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

crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed

When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405

CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopekcsr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sevioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)

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

smb: client: fix OOB read in smb2ioctlqueryinfo QUERYINFO path

smb2ioctlqueryinfo() has two response-copy branches: PASSTHRUFSCTL and the default QUERYINFO path. The QUERYINFO branch clamps qi.inputbufferlength to the server-reported OutputBufferLength and then copies qi.inputbufferlength bytes from qirsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rspiov[1].iov_len.

A malicious server can return OutputBufferLength larger than the actual QUERYINFO response, causing copyto_user() to walk past the response buffer and expose adjacent kernel heap to userspace.

Guard the QUERYINFO copy with a bounds check on the actual Buffer payload. Use structsize(qirsp, Buffer, qi.inputbuffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)

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

vxlan: validate ND option lengths in vxlannacreate

vxlannacreate() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31738)

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

usb: cdns3: gadget: fix NULL pointer dereference in ep_queue

When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when _cdns3gadgetepqueue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.

This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)

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

Bluetooth: hci_event: move wake reason storage into validated event handlers

hcistorewakereason() is called from hcieventpacket() immediately after stripping the HCI event header but before hcieventfunc() enforces the per-event minimum payload length from hciev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.

Rather than duplicating skb parsing and per-event length checks inside hcistorewakereason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hcistorewakereason() into a small helper that only stores an already-validated bdaddr while the caller holds hcidevlock(). Use the same helper after hcieventfunc() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.

Annotate the helper with _musthold(&hdev->lock) and add lockdepassertheld(&hdev->lock) so future call paths keep the lock contract explicit.

Call the helper from hciconnrequestevt(), hciconncompleteevt(), hcisyncconncompleteevt(), leconncompleteevt(), hcileadvreportevt(), hcileextadvreportevt(), hciledirectadvreportevt(), hcilepasyncestablishedevt(), and hcilepastreceivedevt().(CVE-2026-31771)

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

Bluetooth: SMP: derive legacy responder STK authentication from MITM state

The legacy responder path in smprandom() currently labels the stored STK as authenticated whenever pendingseclevel is BTSECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved.

For Just Works/Confirm legacy pairing, SMPFLAGMITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.

This also keeps the legacy path aligned with the Secure Connections code, which already treats JUSTWORKS/JUSTCFM as unauthenticated.(CVE-2026-31773)

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

wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwlmvmndmatchinfo_handler()

The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)

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

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.(CVE-2026-31781)

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

Bluetooth: MGMT: validate LTK enc_size on load

Load Long Term Keys stores the user-provided encsize and later uses it to size fixed-size stack operations when replying to LE LTK requests. An encsize larger than the 16-byte key buffer can therefore overflow the reply stack buffer.

Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.(CVE-2026-43020)

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

net: use skbheaderpointer() for TCPv4 GSO frag_off check

Syzbot reported a KMSAN uninit-value warning in gsofeaturescheck() called from netifskbfeatures() [1].

gsofeaturescheck() reads iph->fragoff to decide whether to clear mangleidfeatures. Accessing the IPv4 header via iphdr()/inneriphdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PFPACKET paths.

Use skbheaderpointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying.

[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)

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

net: ipv6: ndisc: fix ndiscrauseropt to initialize nduseropt_padX fields to zero to prevent an info-leak

When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data

The fix is simple, just zeroes the padding fields.(CVE-2026-43040)

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

crypto: af-alg - fix NULL pointer dereference in scatterwalk

The AFALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new afalgtsgl structure. If a sendmsg() fills an SGL exactly to MAXSGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry.

This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference.

Fix this by explicitly unmarking the end of the previous SGL when performing sgchain() in afalgalloctsgl().(CVE-2026-43043)

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

dmaengine: idxd: Fix not releasing workqueue on .release()

The workqueue associated with an DSA/IAA device is not released when the object is freed.(CVE-2026-43064)

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

perf/x86/intel/uncore: Skip discovery table for offline dies

This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0.

WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncorepcipmuregister+0x136/0x160 [inteluncore]

Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncorepcipmu_register(), which may trigger the warning above or cause other issues.(CVE-2026-43079)

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

powerpc/smp: Add check for kcalloc() failure in parsethreadgroups()

As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to ofpropertyreadu32array().(CVE-2026-43148)

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

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.(CVE-2026-43212)

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

gfs2: fiemap page fault fix

In gfs2fiemap(), we are calling iomapfiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault.

Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary.

Fixes xfstest generic/742.(CVE-2026-43262)

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

ceph: supply snapshot context in cephzeropartial_object()

The cephzeropartial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots.

Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph (CVE-2026-43273)

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

net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.

Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitfor_completion().

At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.(CVE-2026-43345)

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

ceph: fix memory leaks in cephmdscbuild_path()

Add __putname() calls to error code paths that did not free the "path" pointer obtained by _getname(). If ownership of this pointer is not passed to the caller via pathinfo.path, the function must free it before returning.(CVE-2026-43419)

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

USB: core: Limit the length of unkillable synchronous timeouts

The usbcontrolmsg(), usbbulkmsg(), and usbinterruptmsg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.

To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)

In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAYBACKLOG requests MAYBACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)

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

net: skbuff: propagate shared-frag marker through frag-transfer helpers

Two frag-transfer helpers (__pskbcopyfclone() and skbshift()) fail to propagate the SKBFLSHAREDFRAG bit in skbshinfo()->flags when moving frags from source to destination. pskbcopyfclone() defers the rest of the shinfo metadata to skbcopyheader() after copying frag descriptors, but that helper only carries over gso{size,segs, type} and never touches skbshinfo()->flags; skbshift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skbhassharedfrag() as false.

The mismatch is harmful in any in-place writer that uses skbhassharedfrag() to decide whether shared pages must be detoured through skbcowdata(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nfdupipv4() / xtTEE caller -- is enough to land a pskbcopy()'d skb in espinput() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.

Set SKBFLSHAREDFRAG on the destination whenever frag descriptors were actually moved from the source. skbcopy() and skbcopyexpand() share skbcopyheader() too but linearize all paged data into freshly allocated head storage and emerge with nrfrags == 0, so skbhasshared_frag() returns false on its own; they need no change.

The same omission exists in skbgroreceive() and skbgroreceivelist(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the headfrag + memcpy path); the latter chains the incoming skb whole onto p's fraglist. Downstream skbsegment() reads only skbshinfo(p)->flags, and skbsegment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcpclonepayload(), which builds an MTU probe skb by moving frag descriptors from skbs on skwritequeue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.

The same omission exists in skbsegment(): the per-iteration flag merge takes only headskb's flag, and the inner switch that rebinds fragskb to listskb on headskb-frags exhaustion does not fold the new fragskb's flag into nskb. Fold fragskb's flag at both sites so segments drawing frags from fraglist members carry the marker.(CVE-2026-43503)