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

tls: fix use-after-free on failed backlog decryption

When the decrypt request goes to the backlog and cryptoaeaddecrypt returns -EBUSY, tlsdodecryption will wait until all async decryptions have completed. If one of them fails, tlsdodecryption will return -EBADMSG and tlsdecryptsg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tlsdecryptdone.

The only true async case is when cryptoaeaddecrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tlsswrecvmsg that the data is available for immediate copy, but we need to notify tlsdecryptsg (via the new ->asyncdone flag) that the memory has already been released.

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

smb: client: fix potential UAF in smb2isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

virtio-net: fix overflow inside virtnetrqalloc

When the frag just got a page, then may lead to regression on VM. Specially if the sysctl net.core.highorderallocdisable value is 1, then the frag always get a page when do refill.

Which could see reliable crashes or scp failure (scp a file 100M in size to VM).

The issue is that the virtnetrqdma takes up 16 bytes at the beginning of a new frag. When the frag size is larger than PAGESIZE, everything is fine. However, if the frag is only one page and the total size of the buffer and virtnetrqdma is larger than one page, an overflow may occur.

The commit f9dac92ba908 ("virtioring: enable premapped mode whatever usedmaapi") introduced this problem. And we reverted some commits to fix this in last linux version. Now we try to enable it and fix this bug directly.

Here, when the frag size is not enough, we reduce the buffer len to fix this problem.

bnxten: Set DMA unmap len correctly for XDPREDIRECT

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

smb: client: fix use-after-free in cryptmessage when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from cryptmessage(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);

// Async encryption returns -EINPROGRESS immediately rc = enc ? cryptoaeadencrypt(req) : cryptoaeaddecrypt(req);

// Free creq while async operation is still in progress kvfreesensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowaitreq() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.

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

net/mlx5e: SHAMPO, Fix incorrect page release

Under the following conditions: 1) No skb created yet 2) headersize == 0 (no SHAMPO header) 3) headerindex + 1 % MLX5ESHAMPOWQHEADERPERPAGE == 0 (this is the last page fragment of a SHAMPO header page)

a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5ehandlerxcqempwrqshampo()), a SHAMPO header page from headerindex is released. This is wrong and it leads to SHAMPO header pages being released more than once.

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

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.

Bluetooth: hcievent: Ignore multiple conn complete events

Bluetooth: L2CAP: Fix slab-use-after-free Read in l2capsendcmd

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.

9p/net: fix improper handling of bogus negative read/write replies

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

KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).

This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:

1) Creating a KVM VM and vCPU 2) Sending a KVMSMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault

The issue manifests as follows:

WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdowninterception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svminvokeexithandler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svmhandleexit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpuenterguest arch/x86/kvm/x86.c:10959 [inline] vcpurun+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvmarchvcpuioctlrun+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvmvcpuioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvmmain.c:4122 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:870 [inline] sesysioctl fs/ioctl.c:856 [inline] x64sysioctl+0x19a/0x210 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8

Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvmvcpureset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do something sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.

So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

[sean: massage changelog, make it clear this isn't architectural behavior]

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

wifi: cfg80211: Add missing lock in cfg80211checkandendcac()

Callers of wdevchandef() must hold the wiphy mutex.

But the worker cfg80211propagatecacdonewk() never takes the lock. Which triggers the warning below with the meshpeerconnecteddfs test from hostapd and not (yet) released mac80211 code changes:

WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdevchandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211propagatecacdonewk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? printk+0x0/0x98 [<6003c2b3>] showstack+0x10e/0x11a [<6002ec30>] ? printk+0x0/0x98 [<60037608>] dumpstacklvl+0x71/0xb8 [<6063717b>] ? wdevchandef+0x60/0x165 [<6003766d>] dumpstack+0x1e/0x20 [<6005d1b7>] warn+0x101/0x20f [<6005d3a8>] warnslowpathfmt+0xe3/0x15d [<600b0c5c>] ? marklock.part.0+0x0/0x4ec [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<600b11a2>] ? markheldlocks+0x5a/0x6e [<6005d2c5>] ? warnslowpathfmt+0x0/0x15d [<60052e53>] ? unblocksignals+0x3a/0xe7 [<60052f2d>] ? umsetsignals+0x2d/0x43 [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<607508b2>] ? lockisheldtype+0x207/0x21f [<6063717b>] wdevchandef+0x60/0x165 [<605f89b4>] regulatorypropagatedfsstate+0x247/0x43f [<60052f00>] ? umsetsignals+0x0/0x43 [<605e6bfd>] cfg80211propagatecacdonewk+0x3a/0x4a [<6007e460>] processscheduledworks+0x3bc/0x60e [<6007d0ec>] ? movelinkedworks+0x4d/0x81 [<6007d120>] ? assignwork+0x0/0xaa [<6007f81f>] workerthread+0x220/0x2dc [<600786ef>] ? setpfworker+0x0/0x57 [<60087c96>] ? tokthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? workerthread+0x0/0x2dc [<6006c05b>] ? calculatesigpending+0x0/0x56 [<6003b37d>] newthreadhandler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] upconsolesem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] upconsolesem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] ieee80211wakequeue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] ieee80211wakequeue+0x643/0x985

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

rxrpc: Fix handling of received connection abort

Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.

Also add some tracing for the logging of connection aborts.

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

ksmbd: fix null pointer dereference in destroyprevioussession

If client set ->PreviousSessionId on kerberos session setup stage, NULL pointer dereference error will happen. Since sess->user is not set yet, It can pass the user argument as NULL to destroyprevioussession. sess->user will be set in ksmbdkrb5authenticate(). So this patch move calling destroyprevioussession() after ksmbdkrb5authenticate().

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

scsi: target: Fix NULL pointer dereference in corescsi3decodespeciport()

The function corescsi3decodespeciport(), in its error code path, unconditionally calls corescsi3lunaclundependitem() passing the destsedeve pointer, which may be NULL.

This can lead to a NULL pointer dereference if destsedeve remains unset.

SPC-3 PR SPECIPT: Unable to locate desttpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: corescsi3lunaclundependitem+0x2c/0xf0 [targetcoremod] (P) corescsi3decodespeciport+0x120c/0x1c30 [targetcoremod] corescsi3emulateproregister+0x6b8/0xcd8 [targetcoremod] targetscsi3emulateprout+0x56c/0x840 [targetcoremod]

Fix this by adding a NULL check before calling corescsi3lunaclundependitem()

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

nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec

Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2CDATA PDUs.

The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2CDATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.

Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2CDATA PDU for uninitialized command slot → both pointers NULL

The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated

hvnetvsc: Don't free decrypted memory

bpf: Guard stack limits against 32bit overflow

dma-buf/dma-resv: check if the new fence is really later

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

netfilter: nftsetpipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following multiplication does not overflow:

- desc->fieldlen[] maximum value is U8MAX multiplied by NFTPIPAPOGROUPSPERBYTE(f) that can be 2, worst case. - NFTPIPAPOBUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(f->lt), lt in struct nftpipapofield.

Then, use checkmuloverflow() to multiply by bucket size and then use checkaddoverflow() to the alignment for avx2 (if needed). Finally, add ltsizecheckoverflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFPKERNEL to GFPKERNELACCOUNT for consistency, in pipaporesize().

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

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.

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

ipv6: reject malicious packets in ipv6gsosegment()

syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transportheader.

This 16bit field has a limited range.

Add skbresettransportheadercareful() helper and use it from ipv6gsosegment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skbresettransportheader include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skbresettransportheader include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Call Trace: <TASK> skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 nshgsosegment+0x54a/0xe10 net/nsh/nsh.c:110 skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 skbgsosegment+0x342/0x510 net/core/gso.c:124 skbgsosegment include/net/gso.h:83 [inline] validatexmitskb+0x857/0x11b0 net/core/dev.c:3950 validatexmitskblist+0x84/0x120 net/core/dev.c:4000 schdirectxmit+0xd3/0x4b0 net/sched/schgeneric.c:329 devxmitskb net/core/dev.c:4102 [inline] devqueuexmit+0x17b6/0x3a70 net/core/dev.c:4679

igc: avoid returning frame twice in XDPREDIRECT

bpf: support non-r10 register spill/fill to/from stack in precision tracking

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

bpf: Do markchainprecision for ARGCONSTALLOCSIZEORZERO