OESA-2026-2311

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/vmwgfx: Return the correct value in vmwtranslateptr functions

Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.

The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTRERR of the now uninitialized pointer. This could cause the vmwtranslate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)

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

NFSD: Defer sub-object cleanup in export put callbacks

svcexportput() calls pathput() and authdomainput() immediately when the last reference drops, before the RCU grace period. RCU readers in eshow() and cshow() access both expath (via seqpath/dpath) and exclient->name (via seqescape) without holding a reference. If cacheclean removes the entry and drops the last reference concurrently, the sub-objects are freed while still in use, producing a NULL pointer dereference in dpath.

Commit 2530766492ec ("nfsd: fix UAF when access exuuid or exstats") moved kfree of exuuid and exstats into the callrcu callback, but left pathput() and authdomainput() running before the grace period because both may sleep and call_rcu callbacks execute in softirq context.

Replace callrcu/kfreercu with queuercuwork(), which defers the callback until after the RCU grace period and executes it in process context where sleeping is permitted. This allows pathput() and authdomainput() to be moved into the deferred callback alongside the other resource releases. Apply the same fix to expkeyput(), which has the identical pattern with ekpath and ekclient.

A dedicated workqueue scopes the shutdown drain to only NFSD export release work items; flushing the shared systemunboundwq would stall on unrelated work from other subsystems. nfsdexportshutdown() uses rcubarrier() followed by flushworkqueue() to ensure all deferred release callbacks complete before the export caches are destroyed.

Reviwed-by: Jeff Layton <(CVE-2026-31404)

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

net: bonding: fix use-after-free in bondxmitbroadcast()

bondxmitbroadcast() reuses the original skb for the last slave (determined by bondislast_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed).

Replace the racy bondislastslave() check with a simple index comparison (i + 1 == slavescount) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations.

The UAF can trigger the following crash:

================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147

CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:597) skbclone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5334) bondstartxmit (drivers/net/bonding/bondmain.c:5567 drivers/net/bonding/bondmain.c:5593) devhardstartxmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __devqueuexmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6finishoutput2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6output.c:136) ip6finishoutput (net/ipv6/ip6output.c:208 net/ipv6/ip6output.c:219) ip6output (net/ipv6/ip6output.c:250) ip6sendskb (net/ipv6/ip6output.c:1985) udpv6sendskb (net/ipv6/udp.c:1442) udpv6sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Allocated by task 147:

Freed by task 147:

The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuffheadcache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)

Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================(CVE-2026-31419)

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

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

idxdwqdisable_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:

ext4: avoid infinite loops caused by residual data

On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4extmapblocks() only calls ext4free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously.

The above causes ext4xattrblock_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1].

If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4GETBLOCKSDELALLOCRESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases:

1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case.

2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks.

[1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inodelocknested include/linux/fs.h:1073 [inline] __startdirop fs/namei.c:2923 [inline] startdirop fs/namei.c:2934 inline

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

ksmbd: do not expire session on binding failure

When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2SESSIONEXPIRED. However, during binding, sess points to the target session looked up via ksmbdsessionlookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS).

Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbdsessionlookupslowpath() is still correctly released via ksmbdusersessionput().(CVE-2026-31476)

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

net: fix fanout UAF in packetrelease() via NETDEVUP race

packet_release() has a race window where NETDEV_UP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanout_release(), leaving a dangling pointer in the fanout array. packet_release() does NOT zero po->num in its bind_lock section. After releasing bind_lock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packet_notifier(NETDEV_UP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls __fanout_link(sk, po) which adds the socket back into f->arr[] and increments f->num_members, but does NOT increment f->sk_ref.

The fix sets po->num to zero in packet_release while bind_lock is held to prevent NETDEV_UP from linking, preventing the race window.

This bug was found following an additional audit with Claude Code based on CVE-2025-38617.(CVE-2026-31504)

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

afkey: validate families in pfkeysend_migrate()

syzbot was able to trigger a crash in skb_put() [1]

Issue is that pfkeysendmigrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb.

Validate families early, do not wait set_ipsecrequest().

[1]

skbuff: skboverpanic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<NULL> kernel BUG at net/core/skbuff.c:214 ! Call Trace: <TASK> skboverpanic net/core/skbuff.c:219 [inline] skbput+0x159/0x210 net/core/skbuff.c:2655 skbputzero include/linux/skbuff.h:2788 [inline] setipsecrequest net/key/afkey.c:3532 [inline] pfkeysendmigrate+0x1270/0x2e50 net/key/afkey.c:3636 kmmigrate+0x155/0x260 net/xfrm/xfrmstate.c:2848 xfrmmigrate+0x2140/0x2450 net/xfrm/xfrmpolicy.c:4705 xfrmdomigrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150(CVE-2026-31515)

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

module: Fix kernel panic when a symbol st_shndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplify_symbols():

   for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
    const char *name = info->strtab + sym[i].st_name;

    switch (sym[i].st_shndx) {
    case SHN_COMMON:

    [...]

    default:
        /* Divert to percpu allocation if a percpu var. */
        if (sym[i].st_shndx == info->index.pcpu)
            secbase = (unsigned long)mod_percpu(mod);
        else

/** HERE --> **/ secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].st_value += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHN_HIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/(CVE-2026-31521)

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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.(CVE-2026-31523)

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:

spi: spi-dw-dma: fix print error log when wait finish transaction

If an error occurs, the device may not have a current message. In this case, the system will crash.

In this case, it's better to use dev from the struct ctlr (struct spi_controller*).(CVE-2026-31560)

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

KVM: SEV: Protect all of sevmemencregisterregion() with kvm->lock

Take and hold kvm->lock for before checking sevguest() in sevmemencregisterregion(), as sevguest() isn't stable unless kvm->lock is held (or KVM can guarantee KVMSEVINIT{2} has completed and can't rollack state). If KVMSEVINIT{2} fails, KVM can end up trying to add to a not-yet-initialized sev->regions_list, e.g. triggering a #GP

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sevmemencregisterregion+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: <TASK> kvmarchvmioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvmvmioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 _sesysioctl+0x101/0x170 ../fs/ioctl.c:51 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x6f/0x1f0 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 </TASK>

with a syzlang reproducer that looks like:

syzkvmaddvcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syzkvmaddvcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVMCREATEVM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVMCREATEVM(r2, 0xae01, 0x0) ioctl$KVMSETCLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVMSETPIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVMSETPIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVMCREATEVM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVMSETUSERMEMORYREGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVMCREATEVCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVMSETGUESTDEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVMRUN(r5, 0xae80, 0x0)

Opportunistically use guard() to avoid having to define a new error label and goto usage.(CVE-2026-31592)

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:

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:

afunix: read UNIXDIAGVFS data under unixstate_lock

Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unixreleasesock() clears u->path under unixstatelock() and drops the path reference after unlocking.

Read the inode and device numbers for UNIXDIAGVFS while holding unixstatelock(), then emit the netlink attribute after dropping the lock.

This keeps the VFS data stable while the reply is being built.(CVE-2026-31673)

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

netfilter: ip6trt: reject oversized addrnr in rtmt6_check()

Reject rt match rules whose addrnr exceeds IP6TRTHOPS.

rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.(CVE-2026-31674)

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

openvswitch: validate MPLS set/set_masked payload length

validateset() accepted OVSKEYATTRMPLS as variable-sized payload for SET/SETMASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovskey_mpls).

Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes.

Reject invalid MPLS action payload lengths early.(CVE-2026-31679)

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

bridge: brndsend: linearize skb before parsing ND options

brndsend() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request.

Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer.

Linearize request before option parsing and derive ns from the linear network header.(CVE-2026-31682)

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:

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:

xen/privcmd: fix double free via VMA splitting

privcmdvmops defines .close (privcmdclose), but neither .maysplit nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __splitvma(). Since maysplit is NULL, the split is allowed. vmareadup() copies vmprivatedata (a pages array allocated in allocemptypages()) into the new VMA without any fixup, because there is no .open callback.

Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmdclose() calls: - xenunmapdomaingfnrange() - xenfreeunpopulatedpages() - kvfree(pages)

The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free.

Fix this issue by adding a .may_split callback denying the VMA split.

This is XSA-487 / CVE-2026-31787(CVE-2026-31787)

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:

HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure

Presently, if the force feedback initialisation fails when probing the Logitech G920 Driving Force Racing Wheel for Xbox One, an error number will be returned and propagated before the userspace infrastructure (sysfs and /dev/input) has been torn down. If userspace ignores the errors and continues to use its references to these dangling entities, a UAF will promptly follow.

We have 2 options; continue to return the error, but ensure that all of the infrastructure is torn down accordingly or continue to treat this condition as a warning by emitting the message but returning success. It is thought that the original author's intention was to emit the warning but keep the device functional, less the force feedback feature, so let's go with that.(CVE-2026-43049)

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:

pstore: ram_core: fix incorrect success return when vmap() fails

In persistentramvmap(), vmap() may return NULL on failure.

If offset is non-zero, adding offsetinpage(start) causes the function to return a non-NULL pointer even though the mapping failed. persistentrambuffer_map() therefore incorrectly returns success.

Subsequent access to prz->buffer may dereference an invalid address and cause crashes.

Add proper NULL checking for vmap() failures.(CVE-2026-43124)

In the Linux kernel xfrm/ESP (IPsec) subsystem, when appending pipe pages to network packets (skb) via zero-copy mechanisms such as splice() / MSGSPLICEPAGES, IPv4/IPv6 datagram paths are not correctly marked with the SKBFLSHAREDFRAG flag. The ESP receive path incorrectly treats these externally owned shared pages as private data, skipping the COW (copy-on-write) step and performing in-place decryption directly, allowing an attacker to pollute otherwise read-only pages in the page cache. Combined with CVE-2026-43500, a complete exploit chain can be formed, allowing local unprivileged users to obtain root privileges. This vulnerability affects almost all Linux distributions since 2017 (kernel ~ 4.10), including Ubuntu, RHEL, AlmaLinux, Debian, Fedora, etc. A public PoC has been released and signs of active exploitation have been observed.(CVE-2026-43284)