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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

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

netfilter: nfqueue: hold bridge skb->dev while queued

brpassframeup() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCALIN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection.

When the verdict is reinjected later, brnetifreceiveskb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free.

Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEVDOWN handling.

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

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

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

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

Fix both:

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

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

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

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

net: guard timestamp cmsgs to real error queue skbs

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

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

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

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

net: skbuff: fix missing zerocopy reference in pskbcarve helpers

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

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

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

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

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

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

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

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

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

netfilter: nftexthdr: fix register tracking for FPRESENT flag

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

Bail out if userspace requests too much data when FPRESENT is set.

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

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

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

netfilter: nflog: validate MAC header was set before dumping it

The fallback path of dumpmacheader() guards the MAC header access only with "skb->macheader != skb->networkheader", without checking skbmacheaderwasset(). When the MAC header is unset, macheader is 0xffff, so the test passes and skbmacheader(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hardheaderlen bytes out of bounds into the kernel log.

This is reachable via the netdev logger: nflogunknownpacket() calls dumpmacheader() unconditionally, and an skb sent through AFPACKET with PACKETQDISCBYPASS reaches the egress hook with macheader still unset (devqueuexmit(), which would reset it, is bypassed).

Add the skbmacheaderwasset() check the ARPHRDETHER path already uses, and replace the open-coded MAC header length test with skbmacheaderlen(). Only skbs with an unset MAC header are affected; valid ones are dumped as before.

BUG: KASAN: slab-out-of-bounds in dumpmacheader (net/netfilter/nflogsyslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasanreport (mm/kasan/report.c:595) dumpmacheader (net/netfilter/nflogsyslog.c:831) nflognetdevpacket (net/netfilter/nflogsyslog.c:938 net/netfilter/nflogsyslog.c:963) nflogpacket (net/netfilter/nflog.c:260) nftlogeval (net/netfilter/nftlog.c:60) nftdochain (net/netfilter/nftablescore.c:285) nftdochainnetdev (net/netfilter/nftchainfilter.c:307) nfhookslow (net/netfilter/core.c:619) nfhookdirectegress (net/packet/afpacket.c:257) packetxmit (net/packet/afpacket.c:280) packetsendmsg (net/packet/afpacket.c:3114) syssendto (net/socket.c:2265)

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

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

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

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

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

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

tcp: restrict SOATTACHFILTER to priv users

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

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

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

netfilter: xtables: avoid leaking percpu counter pointers

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

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

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

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

netfilter: synproxy: add mutex to guard hook reference counting

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

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

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

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

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

Race:

CPU0 (XFRMMSGDELPOLICY) CPU1 (XFRMMSGNEWSPDINFO) ========================== ========================== xfrmpolicybyselctx(): spinlockbh(xfrmpolicylock) bin = xfrmpolicyinexactlookup() xfrmpolicyunlink(pol) spinunlockbh(xfrmpolicylock) xfrmpolicykill(ret) // wide window, lock not held xfrmhashrebuild(): spinlockbh(xfrmpolicylock) xfrmpolicyinexactflush(): kfreercu(bin) // bin freed spinunlockbh(xfrmpolicylock) xfrmpolicyinexactprunebin(bin) // UAF: bin is freed

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

net: gro: don't merge zcopy skbs

skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.

When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.

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

netfilter: conntrackirc: fix possible out-of-bounds read

When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.

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

ipc/shm: serialize orphan cleanup with shmnattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shmperm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shmperm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

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

ethtool: coalesce: cap profile updates at NETDIMPARAMSNUMPROFILES

ethnlupdateprofile() walks the ETHTOOLAPROFILEIRQMODERATION nest list with an index 'i' and writes newprofile[i++] without bounding i. The destination is kmemdup()'d at NETDIMPARAMSNUMPROFILES entries (5), but the Netlink nest count is entirely user-controlled. Netlink policies do not have support for constraining the number of nested entries (or number of multi-attr entries).

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

netfs: Fix early put of sink folio in netfsreadgaps()

Fix netfsreadgaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITERBVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps.

The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket:

BUG: KASAN: use-after-free in copytoiter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dumpstacklvl+0x5d/0x80 printreport+0x17f/0x4f1 kasanreport+0x100/0x1e0 kasancheckrange+0x10f/0x1e0 asanmemcpy+0x3c/0x60 copytoiter+0x48a/0xa20 skbdatagramiter+0x2c9/0x430 skbcopydatagramiter+0x6e/0x160 tcprecvmsglocked+0xce0/0x1130 tcprecvmsg+0xeb/0x300 inetrecvmsg+0xcf/0x3a0 sockrecvmsg+0xea/0x100 cifsreadvfromsocket+0x3a6/0x4d0 [cifs] cifsreaditerfromsocket+0xdd/0x130 [cifs] cifsreadvreceive+0xaad/0xb10 [cifs] cifsdemultiplexthread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210

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

netfs: Fix potential for tearing in ->remoteisize and ->zeropoint

Fix potential tearing in using ->remoteisize and ->zeropoint by copying isizeread() and isizewrite() and using the same seqcount as for isize.

We need to make sure that netfslib and the filesystems that use it always hold ilock whilst updating any of the sizes to prevent isizeseqcount from getting corrupted.

In multiple functions of sock.c, there is a possible use-after-free due to a race condition. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In multiple locations, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

sctp: stream: fully roll back denied add-stream state

When ADDOUTSTREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path.

Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctpstreamoutqmigrate(), and then reschedule the remaining streams.

This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.

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

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

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

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

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

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

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

Let's illustrate the new restored code path:

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

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

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

vsock/virtio: fix zerocopy completion for multi-skb sends

When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification.

Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skbzcopyset(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via netzcopyputabort().

This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSGZEROCOPY pinned-pages accounting") but was pre-existing.

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

USB: serial: mxuport: fix memory corruption with small endpoint

Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size.

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

usb: typec: tcpm: bound altmodedesc[] per iteration in svdmconsumemodes()

svdmconsumemodes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop.

In the well-behaved SVDM discovery flow this is harmless because each of at most SVIDDISCOVERYMAX SVIDs contributes at most MODEDISCOVERYMAX modes, exactly filling altmodedesc[ALTMODEDISCOVERYMAX]. But the CMDTRSPACK handler in tcpmpdsvdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODEDISCOVERYMAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmodedesc[]. For modedataprime the next field in struct tcpmport is the partneraltmode[] pointer array, which then receives partner-chosen SVID/VDO bytes.

Move the bound check inside the loop so the array can never be indexed past ALTMODEDISCOVERYMAX regardless of how many VDOs the partner supplies or how the function was reached.

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

vsock/virtio: bind uarg before filling zerocopy skb

virtiotransportsendpktinfo() allocates or reuses the zerocopy uarg before entering the send loop, but virtiotransportallocskb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAXSKBFRAGS, iosgfromiter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfreeskb() to free an skb that carries SKBFLMANAGEDFRAGREFS but no uarg, so skbreleasedata() falls through to ordinary frag unref.

Pass the uarg into virtiotransportallocskb() and bind it immediately before virtiotransportfillskb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.

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

vsock/vmci: fix UAF when peer resets connection during handshake

vmcitransportrecvconnectingserver() returned err = 0 for a peer RST in its default switch arm:

err = pkt->type == VMCITRANSPORTPACKETTYPERST ? 0 : -EINVAL;

That made vmcitransportrecvlisten() skip vsockremovepending(), leaving the pending socket on the listener's pendinglinks with skstate = TCPCLOSE while destroy: still dropped the explicit reference taken before scheduledelayedwork().

One second later vsockpendingwork() observed ispending=true and performed full cleanup: vsockremovepending() then the two trailing sockput(sk) calls -- the first reached refcount 0 and skfreed the socket, and the second wrote into the freed object:

BUG: KASAN: slab-use-after-free in refcountwarnsaturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsockpendingwork

Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmcitransportrecvlisten() removes pending from pendinglinks synchronously and vsockpendingwork() takes the ispending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it.

The pre-existing skacceptqremoved() gap on the err < 0 path of vmcitransportrecvlisten() that Sashiko also noted is not introduced or changed by this patch.

Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.

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

tun: free page on short-frame rejection in tunxdpone()

tunxdpone() returns -EINVAL on a frame shorter than ETHHLEN without freeing the page that vhostnetbuildxdp() allocated for it. tunsendmsg() discards that -EINVAL and still returns totallen, so vhosttxbatch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk.

A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETHHLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.