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:

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:

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:

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:

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:

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:

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:

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

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:

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: nftct: fix missing expect put in obj eval

nftctexpectobjeval() allocates an expectation and may call nfctexpectrelated(), but never drops its local reference.

Add nfctexpectput(exp) before return to balance allocation.

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:

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:

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:

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:

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.

bpf: Free reuseport cBPF prog after RCU grace period.

Fragnesia is a universal Linux local privilege escalation exploit, discovered by William Bowling with the V12 team. Fragnesia is a member of the Dirty Frag vulnerability class. This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.

The technique extends the page-cache write bug class that includes Dirty Pipe: when a TCP socket transitions to espintcp ULP mode after data has already been spliced from a file into the receive queue, the kernel processes the queued file pages as ESP ciphertext. The AES-GCM keystream byte at counter block position 2, byte 0 is XORed directly into the cached file page. By selecting the IV nonce to produce a desired keystream byte, any target byte in the file can be set to any value — one byte per trigger invocation.

The exploit builds a 256-entry lookup table mapping each possible keystream byte to its corresponding nonce, then iterates over a payload, firing the splice/ULP race for each byte that needs changing. It writes a small position-independent ELF stub (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of /usr/bin/su in the page cache, then calls execve("/usr/bin/su") to obtain a root shell. The page cache modification is not backed to disk; the on-disk binary is untouched.

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

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

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

struct iflavfbroadcast vfbroadcast;

The struct contains a single fixed 32-byte field:

/ include/uapi/linux/iflink.h / struct iflavfbroadcast { u8 broadcast[32]; };

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

memcpy(vfbroadcast.broadcast, dev->broadcast, dev->addrlen);

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

nlaput(skb, IFLAVFBROADCAST, sizeof(vfbroadcast), &vfbroadcast)

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

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

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

Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf structs in the same function.

exit: prevent preemption of oopsing TASKDEAD task

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

xfrm: ah: account for ESN high bits in async callbacks

AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or authdata area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent.

With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift:

ah4 outputdone: esn=1 err=0 icvoff=20 expectedoff=24 ah4 inputdone: esn=1 authoff=20 expectedauthoff=24 icvoff=32 expectedicvoff=36

Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved authdata or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot.

Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 outputdone: esn=1 err=0 icvoff=24 expectedoff=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.

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

ipv6: xfrm6: release dst on error in xfrm6rcvencap()

xfrm6rcvencap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6routeinputlookup() returns a referenced dst entry even when the lookup resolves to an error route.

If dst->error is set, xfrm6rcvencap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries.

Release the dst before jumping to the drop path.

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

xfrm: defensively unhash xfrmstate lists in xfrmstatedelete

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

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

Workqueue: netns cleanupnet Call Trace: hlistdel / hlistdelrcu xfrmstatedelete xfrmstatedelete xfrmstateflush xfrmstatefini opsexitlist cleanupnet

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

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

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

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

The defensive change here:

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

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

Reproduction:

- Linux 6.12.47 x8664 + KASANGENERIC + KASANINLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrmstate lifecycle

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

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

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

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

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

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

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

x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache

Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.

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

RDMA/mana: Validate rxhashkeylen

Sashiko points out that rxhashkeylen comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.

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

netfs: Fix missing locking around retry adding new subreqs

Fix netfsretryreadsubrequests() and netfsretrywritestream() to take the appropriate lock when adding extra subrequests into stream->subrequests.

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

ipc: limit nextid allocation to the valid ID range

The checkpoint/restore sysctl path can request the next SysV IPC id through ids->nextid. ipcidralloc() currently forwards that request to idralloc() with an open-ended upper bound.

If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipcmni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.

The bug is in ipcidralloc() in the checkpoint/restore path.

1. ids->nextid is passed to:

idralloc(&ids->ipcsidr, new, ipcidtoidx(nextid), 0, ...)

2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idralloc() can spill past ipcmni and allocate an entry beyond the valid IPC id range.

3. The new object id is still encoded with the narrower SysV IPC index width:

new->id = (new->seq << ipcmniseqshift()) + idx

4. Later removal goes through ipcrmid(), which uses:

ipcidtoidx(ipcp->id)

That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.

5. For shared memory, shmdestroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.

6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.

Prevent this by bounding the requested allocation to ipcmni so the checkpoint/restore path fails once the valid range is exhausted.