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

netfilter: nfconntracksip: widen NAT rewrite delta to s32 in siphelptcp()

siphelptcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16MAX while the packet stays under the 65535 enlargeskb() limit: nfnatsip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and "datalen = datalen + diff - msglen" yields a huge unsigned datalen, so the next iteration's ctsipgetheader() reads past the linearized skb tail.

Widen diff, tdiff and the seqadjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nfctseqadjset() takes s32), so no previously accepted input is rejected.

BUG: KASAN: use-after-free in ctsipgetheader (net/netfilter/nfconntracksip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ctsipgetheader (net/netfilter/nfconntracksip.c:464) siphelptcp (net/netfilter/nfconntracksip.c:1694) nfconfirm (net/netfilter/nfconntrackproto.c:183) nfhookslow (net/netfilter/core.c:619) ip6output (net/ipv6/ip6output.c:246) ip6forward (net/ipv6/ip6output.c:690) ipv6rcv (net/ipv6/ip6input.c:351) netifreceiveskbonecore (net/core/dev.c:6212) processbacklog (net/core/dev.c:6676) napipoll (net/core/dev.c:7735) netrxaction (net/core/dev.c:7955) handlesoftirqs (kernel/softirq.c:622) runksoftirqd (kernel/softirq.c:1076) ...

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

KVM: arm64: vgic: Fix race between LPI release and re-registration

Fix a potential race between decrementing an LPI's reference count and evicting that structure from the LPI xarray.

LPI structures are maintained in the VGIC LPI xarray (dist->lpixa). When the reference count of an LPI structure drops to zero, vgicreleaselpilocked() removes the structure from the xarray and frees it under the xarray lock.

However, the release of an LPI can race with a concurrent LPI re-registration with the same INTID via vgicaddlpi() on another CPU, since the reference count drop and the xarray eviction are not performed in a single atomic step. This can happen e.g. if the guest issues a DISCARD while the LPI is still referenced from a vCPU's active-pending list (aplist), and the same INTID is re-mapped via MAPTI.

Particularly, vgicreleaselpilocked() is called from two distinct paths: direct release via vgicputirq(), and deferred release via vgicreleasedeletedlpis(). During direct release, the issue can result in deleting a newly registered LPI from the xarray:

CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgicputirq() vgicputirq() refcountdecandtest() vgicaddlpi() xalockirqsave() oldirq = xaload(.., intid) vgictrygetirqref(oldirq) == false new IRQ inserted --> xastore(.., intid, ..) xaunlockirqrestore() xalockirqsave(); vgicreleaselpilocked() xaerase(.., irq->intid) <-- BUG: new IRQ is erased kfreercu(oldirq)

During the deferred release path, the old IRQ can be leaked:

CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgicputirqnorelease() vgicputirq() refcountdecandtest() irq->pendingrelease = true vgicaddlpi() xalockirqsave() oldirq = xaload(.., intid) vgictrygetirqref(oldirq) == false BUG: old IRQ overwritten --> xastore(.., intid, ..) xaunlockirqrestore()

vgicreleasedeletedlpis() xalockirqsave() xaforeach() { .. } <-- old IRQ with pendingrelease = true is gone, so it cannot be released

To fix the direct release path, move the reference count drop inside the xarray lock, making sure that vgicaddlpi() never encounters the to-be-released LPI.

In the deferred release path, the refcount drop must happen under a raw spinlock, so the xarray lock cannot be grabbed, and the same solution does not work. Instead, update vgicaddlpi(), so that if it evicts an LPI from the xarray, it takes on the responsibility of freeing it. Consequently, an LPI may now be freed concurrently after a deferred release drops the refcount, so accessing the pendingrelease field is no longer safe from use-after-free. Delete all uses of the flag, and update vgicreleasedeletedlpis() to identify orphaned LPIs purely based on their refcount.

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

net/smc: fix socket use-after-free during link group termination

smclgrterminate() drops connslock after finding a connection in lgr->connsall, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree.

A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sockhold().

The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported:

BUG: KASAN: slab-use-after-free in smclgrterminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smclgrterminatework [smc] smclgrterminate.part.0 [smc]

The socket was allocated by smccreate(), freed through slabfreeafterrcudebug(), and was followed by:

refcountt: addition on 0; use-after-free. smclgrterminate.part.0 [smc]

Take the socket reference while connslock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.

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

veth: convert fraglist skbs before running XDP

A fraglist skb can reach veth with datalen set but nrfrags zero. vethconvertskbtoxdpbuff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skbisnonlinear() to decide whether to set XDPFLAGSHASFRAGS and xdpfragssize.

That exposes fraglist data to XDP as if it were stored in frags[], but frags[] is empty. AFXDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from xskrcv().

Route non-linear skbs through skbppcowdata() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skbcopybits() already handles fraglist input, and skbppcowdata() builds frags[] output with skbaddrxfrag(), which is the representation XDP multi-buffer expects.

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

rxrpc: Fix UAF in rxgkissuechallenge()

Fix rxgkissuechallenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.

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

rxrpc: Fix double unlock in rxrpcrecvmsg()

Fix a double unlock in rxrpcrecvmsg() when dealing with OOB messages.

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

afs: Fix netns teardown to cancel the preallocation charger

Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0).

Also, if net->live is false because the afs netns is being deleted, make afschargepreallocation() skip charging and make afsrxnewcall() avoid requeuing the charger.

(This was found by AI review).

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

RDMA/srpt: fix integer overflow in immediate data length check

immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginitone().

Use checkaddoverflow() to detect wrapping before the comparison.

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

ocfs2: validate fast symlink target during inode read

ocfs2validateinodeblock() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment.

A zero-cluster symlink is treated as a fast symlink and later read through pagegetlink() and ocfs2fastsymlinkreadfolio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an isize that does not fit the inline area or omits the terminating NUL at isize, that copy reads past the end of the inode block buffer.

Reject zero-cluster symlink dinodes whose isize exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at isize when the inode block is validated. This keeps malformed fast symlinks from reaching the read path.

Validation reproduced this kernel report: KASAN use-after-free in ocfs2fastsymlinkreadfolio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dumpstacklvl+0x66/0xa0 (?:?) printreport+0xce/0x630 (?:?) ocfs2fastsymlinkreadfolio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) virtaddrvalid+0x19f/0x330 (?:?) kasanreport+0xe0/0x110 (?:?) kasancheckrange+0x105/0x1b0 (?:?) asanmemcpy+0x23/0x60 (?:?) filemapreadfolio+0x27/0xe0 (?:?) filemapreadfolio+0x35/0xe0 (?:?) doreadcachefolio+0x138/0x230 (?:?) pagegetlink+0x26/0x110 (?:?) pagegetlink+0x2e/0x70 (?:?) vfsreadlink+0x15e/0x250 (?:?) touchatime+0x4d/0x370 (?:?) doreadlinkat+0x186/0x200 (?:?) douseraddrfault+0x65a/0x890 (?:?) x64sysreadlink+0x46/0x60 (?:?) dosyscall64+0x115/0x6a0 (arch/x86/entry/syscall64.c:87) entrySYSCALL64afterhwframe+0x77/0x7f (?:?)

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

net/9p: fix race condition on rdma->state in transrdma.c

The rdma->state field is modified without holding reqlock in both recvdone() and p9cmeventhandler(), while rdmarequest() accesses the same field under the reqlock spinlock. This inconsistent locking creates a race condition:

- recvdone() running in softirq completion context sets rdma->state = P9RDMAFLUSHING without acquiring reqlock

- p9cmeventhandler() modifies rdma->state at multiple points (ADDRRESOLVED, ROUTERESOLVED, ESTABLISHED, CLOSED) without reqlock

- rdmarequest() uses spinlockirqsave(&rdma->reqlock, flags) to protect the read-modify-write of rdma->state

The race can cause lost state transitions: recvdone() or the CM event handler could set state to FLUSHING/CLOSED while rdmarequest() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown.

Fix by adding reqlock protection to all rdma->state modifications in recvdone() and p9cmeventhandler(), matching the pattern already used in rdmarequest(). Use spinlockirqsave/spinunlockirqrestore in the CM event handler since it can race with recvdone() which runs in softirq context.

Tested with a kernel module that races two threads (simulating rdmarequest and recvdone/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.

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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdmaisbcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdrinlinedecode(xdr, 0); / five p++ reads follow /

asks xdrinlinedecode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdrinlinedecode(xdr, 3 sizeof(p)); if (unlikely(!p)) return true;

the short-header arm returns true without calling rpcrdmabcreceivecall(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdmareplyhandler() if (rpcrdmaisbcall(rxprt, rep)) return; / bare return, skips outpost / ... outpost: rpcrdmapostrecvs(rxprt, credits + ...);

Because rpcrdmabcreceivecall() never ran, no one took rep, but rpcrdmareplyhandler still bare-returns past rpcrdmarepput() and rpcrdmapostrecvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rballreps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches outpost and rpcrdmapostrecvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal outnorqst cleanup chain (rpcrdmarepput() plus rpcrdmapostrecvs()).

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

ksmbd: fix use-after-free of conn->preauthinfo in concurrent SMB2 NEGOTIATE

conn->preauthinfo is shared connection state (struct preauthintegrityinfo, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path.

smb2handlenegotiate() allocates conn->preauthinfo, and on a deassemblenegcontexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbdconnlock(conn) (the connection srvmutex), which is held across the whole handler body.

The response send path smb3preauthhashrsp(), called from the send: block of handleksmbdwork(), reads conn->preauthinfo and dereferences conn->preauthinfo->PreauthHashValue (via ksmbdgenpreauthintegrityhash()) without taking connlock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauthinfo on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed).

The send-path read tested conn->preauthinfo for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window.

Serialize the NEGOTIATE-branch read in smb3preauthhashrsp() under ksmbdconnlock(conn) and re-check conn->preauthinfo inside the lock. Because the negotiate handler holds connlock across its kfree + NULL assignment, a reader that also takes connlock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbdgenpreauthintegrityhash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and connlock is a sleepable mutex which is safe on this send path (it already performs network I/O).

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

netfs: Fix netfscreatewritereq() to handle async cache object creation

netfscreatewritereq() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscachebeginwriteoperation() to be skipped.

Fix this by removing the checks on the cookie and delegating this to fscachebeginwriteoperation().

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

SUNRPC: pin upper rpcclnt across the TLS connectworker

The TLS connect path has a use-after-free: nothing pins the upper rpcclnt across the delayed connectworker. xsconnect() stores task->tkclient in sockxprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xstcptlssetupsocket(), which reads several fields out of the saved pointer (cltimeout, clprogram, clprog, clvers, clcred, clstats) to construct the args for the inner handshake rpcclnt.

The xprt does not reference the rpcclnt; the rpcclnt references the xprt. xsdestroy() does cancel the connectworker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpcclnt releases its clxprt reference in rpcfreeclientwork(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpcshutdownclient(), and the upper rpcclnt is freed before the queued connectworker fires. xstcptlssetupsocket() then dereferences the freed clnt, producing the refcountt underflow Michael Nemanov reported.

Take a reference on the upper rpcclnt in xsconnect() for TLS transports via a new rpcholdclient() helper, and drop it in the connectworker's exit path with rpcreleaseclient(). The xprtlockconnect() / xprtunlockconnect() pairing already serialises xsconnect() with xstcptlssetupsocket(), so the take and release are balanced one-for-one.

The non-TLS connect worker (xstcpsetupsocket) never reads sockxprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.

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

netfilter: nfnatsip: reload possible stale data pointer

quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper.

In net/netfilter/nfnatsip.c:nfnatsip(): if (skbensurewritable(skb, skb->len)) { nfcthelperlog(skb, ct, "cannot mangle packet"); return NFDROP; } uh = (void )skb->data + protoff; uh->dest = ctsipinfo->forceddport; if (!nfnatmangleudppacket(skb, ct, ctinfo, protoff, 0, 0, NULL, 0)) {

If a cloned or fragmented SKB is reallocated by skbensurewritable(), the old data buffer is freed. However, nfnatsip() fails to update dptr to point to the new buffer.

It also appears to use nfnatmangleudppacket() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------

nfconntracksip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr.

Disable nfnatmangleudppacket() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise.

The calling conntracksip set ->forceddport for SIPHDRVIAUDP messages, so I don't think this is ever expected to be true for a TCP stream.

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

sunrpc: pin svcxprt across the asynchronous TLS handshake callback

svctcphandshake() stores the raw svcxprt pointer in tlshandshakeargs.tadata and submits the request through tlsserverhellox509(). The handshake core takes only sockhold(req->hrsk); nothing references the embedding struct svcsock that svctcphandshakedone() reaches via containerof().

Two close races leave the in-flight callback writing through a freed svcsock. svcsockfree() calls tlshandshakecancel() and discards its return value: a false return means handshakecomplete() has already set HANDSHAKEFREQCOMPLETED but hpdone() may not have finished, yet svcsockfree() proceeds to kfree(svsk). The cancel-loser fall-through inside svctcphandshake() itself produces the same window: when waitforcompletioninterruptibletimeout() returns <= 0 (timeout or signal) and tlshandshakecancel() returns false, the function does not drain, returns, and svchandlexprt() calls svcxprtreceived(), which clears XPTBUSY and can drop the last reference. A concurrent close then runs svcsockfree() while svctcphandshakedone() is still updating xptflags and walking svsk->skhandshakedone.

The corruption surfaces as setbit/clearbit RMW into the freed xptflags slab slot and as completeall() walking and writing the freed waitqueueheadt list embedded in skhandshakedone -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVCHANDSHAKETO expiry.

Take svcxprtget(xprt) immediately before tlsserverhellox509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tlsserverhellox509() and a successful tlshandshakecancel() -- and at the tail of svctcphandshakedone() after completeall().

[cel: rewrote commit message to describe the actual change]

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

ntfs: grow index root value before reparent header update

ntfsirreparent() moves the resident index root entries into an index block and leaves a small root stub containing the child VCN. That root stub can be larger than the existing resident value. For example, an empty root with valuelength 48 has an index area of 32 bytes, while the large-index root stub needs indexlength and allocatedsize of 40 bytes.

The current code publishes the larger index.indexlength and index.allocatedsize before resizing the resident value. If the resize returns -ENOSPC, the recovery path can call ntfsinodeaddattrlist(), which looks attributes up again while the root header says allocatedsize 40 but the resident value still only provides 32 bytes of index area. Lookup-time $INDEXROOT validation then correctly rejects that transient layout as corrupt.

This reproduces as a generic/013 failure under qemu. In the failing run, the transient root had valuelen=48, indexsize=32, indexlength=40, and allocatedsize=40, and ntfsprogs-plus ntfsck reported "Corrupt index root in MFT record 1177".

When the root stub grows, resize the resident value before publishing the larger root header. If the resize fails, the old root remains valid for recovery lookups. Keep the existing header-before-resize ordering for shrink or same-size cases so the resident value never temporarily exposes an allocatedsize beyond its bounds.

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

ntfs: add bounds check before accessing EA entries

in ntfsealookup and ntfslistxattr, this verifies that there is enough space in the EA entry before accessing the nextentryoffset field of the EA entry.

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

ntfs: validate index entries on reading

Validate index entries immediately after reading an index root or index block from disk. This eliminates repeated checks in lookup and readdir, and reduce the risk of missing checks in those paths.

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

ntfs3: validate split-point offset in indxinsertintobuffer

indxinsertintobuffer() computes

used = used1 - tocopy - spsize; memmove(det, Add2Ptr(sp, spsize), used - le32tocpu(hdr1->deoff));

where sp and spsize come from hdrfindsplit(). hdrfindsplit() walks entries by le16tocpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFSDE). indexhdrcheck(), the on-load gatekeeper, only validates header-level fields (used, total, deoff) and does not walk per-entry sizes.

A crafted NTFS image whose leaf INDEXHDR reports used == total but contains one interior NTFSDE with size = 0xFFF0 therefore passes validation, descends to indxinsertintobuffer() through the ntfscreate() -> indxinsertentry() path, and makes hdrfindsplit() return an sp whose spsize (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel.

Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount).

Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdrfindsplit() contract and relies on the same out: cleanup path as the pre-existing error returns.

A prior OOB read in the very same indxinsertintobuffer() memmove was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in indxinsertintobuffer") by tightening hdrfinde(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdrfindsplit(), not hdrfinde(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.

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

scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE

corescsi3emulateproregisterandmove() maps the PERSISTENT RESERVE OUT parameter list with transportkmapdatasg() and parses the destination TransportID with targetparseprouttransportid(). For an iSCSI TransportID (FORMAT CODE 01b), iscsiparseprouttransportid() returns the ISID in iportptr as a raw pointer into that mapped buffer.

The function then unmaps the buffer with transportkunmapdatasg() before dereferencing iportptr in strcmp(), corescsi3locateprreg() and corescsi3allocregistration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transportkmapdatasg() uses vmap() and transportkunmapdatasg() does vunmap(), so the kernel virtual address backing iportptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region.

Keep the parameter list mapped until iportptr is no longer needed: drop the early transportkunmapdatasg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transportkunmapdatasg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller corescsi3decodespeciport() already uses the buffer before unmapping it and is left unchanged.

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

gve: fix header buffer corruption with header-split and HW-GRO

The DQO RX datapath programs a per-buffer-queue-descriptor headerbufaddr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity:

- post (gverxpostbuffersdqo): headerbufaddr is computed from bufq->tail - read (gverxdqo): the header is read from descidx (the completion queue head index)

This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave.

That results in two problems:

1. Wrong header slot on read. Because the read offset is derived from the completion index (descidx) while the device wrote the header to the address programmed for the buffer's bufid, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams.

2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed.

Fix both issues by indexing the header buffer by bufid on both the post and read paths. Reading from bufid's slot is therefore always correct regardless of completion ordering (fixes problem 1).

Indexing by bufid also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (bufid) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2).

Allocate (gverxallochdrbufs) and free (gverxfreehdrbufs) the header buffers based on numbufstates to match the bufid indexing.

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

orangefs: keep the readdir entry size 64-bit in fillfrompart()

fillfrompart() computes the size of a directory entry in sizet but stores it in a u32. An entry length near U32MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel.

Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.

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

ksmbd: use opener credentials for FSCTL mutations

SETSPARSE, SETZERODATA and SETCOMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask.

Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.

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

xfrm: fix stale skb->prev after async crypto steals a GSO segment

skbgsosegment() leaves the segment list head with ->prev pointing at the last segment, an invariant validatexmitskblist() relies on when it sets its tail pointer (tail = skb->prev).

When validatexmitxfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validatexmitskblist() later does tail->next = skb, writing through that stale pointer -- a use-after-free.

Repoint skb->prev at the last retained segment before returning.

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

smb/client: handle overlapping allocated ranges in fallocate

smb3simplefallocaterange() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC.

The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset.

For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200):

Request: [100, 400) Server range: [ 0, 200) allocated

Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill

Current: [100, 300) skipped [300, 400) zero-filled afterwards

The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled.

Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows.

This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.

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

s390/checksum: Fix csumpartial() without vector facility

Currently csumpartial() calls csumcopy() with copy=false and dst=NULL. On machines without the vector facility, csumcopy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer.

The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().

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

ksmbd: pin conn during async oplock break notification

smb2oplockbreaknoti() and smb2leasebreaknoti() store a ksmbdconn pointer in an async ksmbdwork and then queue that work on ksmbd-io. The work only increments conn->rcount, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbdconn object.

If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbdconnwrite() and ksmbdconnrcountdec().

Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented rcount. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.

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

smb: client: validate DFS referral PathConsumed

parsedfsreferrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing.

If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path.

Validate PathConsumed against the search name length before storing it in the parsed referral.

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

sctp: close UDP tunnel sockets during netns teardown

procsctpdoudpport() starts per-net SCTP UDP tunneling sockets when net.sctp.udpport is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed.

Close the UDP tunnel sockets from sctpctrlsockexit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.