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

xfrm: Fix skb double-free in xfrmdevdirectoutput()

A return value other than 1 from localout() means that the skb has been consumed or its ownership was transferred. xfrmdevdirectoutput() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner.

Return the localout() result directly, matching the ownership handling in xfrmoutputresume().

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

smb: smbdirect: destroy QP before mem pools on accept failure

On the rdmaacceptfailed error path of smbdirectacceptconnectrequest(), the receive io posted just above is owned by the QP (recvio is set to NULL after a successful post). The error path fell through to smbdirectconnectiondestroymempools() before smbdirectconnectiondestroyqp(), so the mem pools and the recvio slab cache were destroyed while that recvio was still outstanding on the QP.

The drain in smbdirectconnectiondestroyqp() (ibdrainqp()) is what runs the recv completion that returns the recvio to the free list, so destroying the pools first leaves the object outstanding at kmemcachedestroy() time ("Slab cache still has objects") and later frees it into an already-destroyed mempool (mempoolfreebulk NULL-pointer dereference).

Give rdmaacceptfailed its own teardown that drains the QP first, then destroys the mem pools, and returns. The remaining labels (postrecviofailed onward) run before the recvio was ever posted, so they keep the mem-pools-then-qp order.

The outstanding recvio at kmemcachedestroy() time:

[ 3487.344647] ============================================================================= [ 3487.349942] BUG smbdirectrecviocacheffff88811ba99000 (Not tainted): Objects remaining on kmemcacheshutdown() [ 3487.356078] ----------------------------------------------------------------------------- [ 3487.356078] [ 3487.356738] Object 0xffff8881511c3440 @offset=13376 [ 3487.358464] Allocated in mempoolallocnoprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempoolallocnoprof+0x18c/0x290 [ 3487.361542] smbdirectconnectioncreatemempools+0x405/0x780 [ 3487.361972] smbdirectacceptconnectrequest+0x5a8/0x1b80 [ 3487.362359] smbdirectlistenrdmaeventhandler+0x1579/0x1b90 [ 3487.362779] cmacmeventhandler+0x9c/0x230 [ 3487.363096] cmaibreqhandler+0x2682/0x45d0 [ 3487.363414] cmprocesswork+0x56/0x3d0 [ 3487.363676] cmworkhandler+0x8a0e/0xd000 [ 3487.367496] processscheduledworks+0xa07/0x13a0 [ 3487.367859] workerthread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] retfromfork+0x3a8/0x7a0 [ 3487.368704] retfromforkasm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2) [ 3487.372840] ------------[ cut here ]------------ [ 3487.373195] WARNING: mm/slub.c:1244 at slaberr+0x1a/0x30, CPU#6: kworker/6:84/22254 [ 3487.373759] Modules linked in: [ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3487.374778] Tainted: [B]=BADPAGE [ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] Workqueue: ibcm cmworkhandler [ 3487.378820] RIP: 0010:slaberr+0x1a/0x30 [ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093 [ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80 [ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080 [ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410 [ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210 [ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300 [ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3487.390440] PKRU: 55555554 [ 3487.390641] Call Trace: [ 3487.390826] <TASK> [ 3 ---truncated---

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

nvmet-auth: Synchronize timeout work during SQ teardown

nvmetauthsqfree() cancels authexpiredwork with canceldelayedwork(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmetsq while nvmetauthexpiredwork() still accesses that SQ.

Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmetsqdestroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.

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

scsi: qla2xxx: Avoid double completion in async IOCB timeout

qla2x00asynciocbtimeout() tries to abort a timed-out async IOCB. When qla24xxasyncabortcmd() fails, both the SRBLOGINCMD path and the SRBCTRLVP/default path scan outstandingcmds[] for the SRB and then call sp->done(sp, QLAFUNCTIONTIMEOUT) unconditionally, without checking whether the SRB was actually found and removed.

If the response ISR completes the same handle first, it removes the SRB under qplockptr and runs sp->done() -> complete(sp->comp). The submitter qla24xxcontrolvp() wakes from waitforcompletion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qlactrlvpspdone(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free.

Track whether this path removed the SRB from outstandingcmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the spfound guard already used in qla24xxabortiocbtimeout().

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

nfsd: set SCSTATUSFREED in nfsd4droprevokedstid for delegations

nfsd4droprevokedstid() handles FREESTATEID for admin-revoked delegations but does not set SCSTATUSFREED before releasing cllock. revokedelegation() uses this flag to detect whether FREESTATEID has already processed the delegation -- without it, the freed delegation is added to clrevoked via listadd(), producing a use-after-free when clrevoked is later traversed in destroyclient().

The SCSTATUSREVOKED path in nfsd4freestateid() (line 7983) already sets SCSTATUSFREED correctly. Apply the same pattern to the SCSTATUSADMINREVOKED path in nfsd4droprevokedstid().

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

nfsd: size fhverify server sockaddr slot by xptlocallen

The nfsdfhverify and nfsdfhverifyerr tracepoints declare the server sockaddr slot sized by xptremotelen but fill it from xptlocal using xptlocallen:

TPSTRUCTentry( ... sockaddr(server, rqstp->rqxprt->xptremotelen) ... ) TPfastassign( ... assignsockaddr(server, &rqstp->rqxprt->xptlocal, rqstp->rqxprt->xptlocallen); ... )

When xptlocallen exceeds xptremotelen, assignsockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xptlocallen < xptremotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers.

The write-past-end case is reachable on NFS/UDP. svcxprtsetremote() is only called from svctcpaccept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svccreatesocket() for UDP calls only svcxprtsetlocal(), so xptremotelen stays 0 for the xprt's lifetime. Every fhverify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xptlocal into a zero-byte slot.

The other NFSD tracepoints that record the server address (NFSDTRACEPROCCALLFIELDS, NFSDTRACEPROCRESFIELDS, SVCRQSTENDPOINTFIELDS) already size the server slot by xptlocallen; nfsdfhverify and nfsdfhverifyerr were the only exceptions.

Fix by sizing the server slot with xptlocallen so the declared slot matches the copy length. The client slot and its assignment already agree on xptremotelen and are left untouched.

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

nfsd: drop the stateid, not the stateowner, on seqidop replay retry

In nfs4preprocessseqidop() the stateid is obtained from nfsd4lookupstateid(), which holds a reference on the nfs4stid (sccount) but takes no reference on the stateowner. openlockstateid() merely casts that stid and likewise takes no reference.

When nfsd4cstateassignreplay() returns -EAGAIN (the replay owner is being torn down, RPUNHASHED) it has not taken a stateowner reference on that path. The error handling nevertheless called nfs4putstateowner(stp->ststateowner), dropping an socount reference the function never acquired -- risking a stateowner refcount underflow and use-after-free -- while leaking the sccount reference held on the stid. The leaked stid reference can also stall a concurrent nfsd4closeopenstateid() waiting for sccount to drop.

Drop the reference actually held -- the stid -- before retrying. The stateowner stays alive through the reference held by the stid. This mirrors the open path in nfsd4processopen1(), where the put balances a reference that path explicitly holds on the stateowner.

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

NFSD: Prevent client use-after-free during delegation revoke

A delegation stateid holds only a bare pointer to its owning nfs4client and does not keep it alive. The client survives its stateids only because destroyclient() drains cldelegations and clrevoked before freeclient() runs.

nfs4laundromat() breaks that invariant: it unhashes an expired delegation from cldelegations, drops deleglock, then revokedelegation() relinks it onto clrevoked under cllock. In that window the delegation is on neither list, so clienthasstate() can report no remaining state.

Every teardown path first requires clrpcusers to be zero, but the laundromat holds no such reference. A client whose recalled delegation has just timed out can therefore reach freeclient() while revokedelegation() is still about to dereference cllock, a use-after-free.

Pin the client with clrpcusers across the revoke so teardown blocks until it completes, then reap the delegation from clrevoked. A client already expiring reaps its own, so skip it and leave the delegation on delrecalllru.

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

ceph: fix UAF in checknewmap() on session freed during unlock

checknewmap() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations. The forced-close path (rank removed from map) correctly takes a reference on s via cephgetmdssession() before releasing mdsc->mutex, but three other paths do not:

Path A (address changed): mutexunlock → mutexlock(&s->smutex) Path B (reconnect): mutexunlock → sendmdsreconnect(mdsc, s) Path C (active transition): mutexunlock → mutexlock(&s->smutex)

Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call unregistersession() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->smutex.

Fix by adding cephgetmdssession(s) before each mutexunlock and cephputmdssession(s) after the corresponding mutexlock, matching the pattern already used in the forced-close path.

Race timeline (Path A):

Thread A (checknewmap) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array)

mutexunlock(&mdsc->mutex) ---> acquires mdsc->mutex unregistersession(mdsc, s) sessions[i] = NULL cephputmdssession(s) refcount: 1 -> 0 kfree(s) <--- freed!

mutexlock(&s->smutex) UAF on freed s->smutex

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

smb: client: clear ce->tgthint in freetgts()

When freetgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cachedfstgt structures.

If ce->tgthint is not reset before it is used later, it results in a use-after-free.

Set ce->tgthint to NULL in freetgts() after the elements are freed to reflect that no elements remain.

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

SUNRPC: wait for in-flight client TLS handshake callback

xstlshandshakesync() gives xstlshandshakedone() a reference to the lower transport before submitting the handshake request. On timeout or signal, the synchronous waiter drops that reference after calling tlshandshakecancel().

handshakereqcancel() returns false when handshakecomplete() has already marked the request complete. In that case the completion callback can still be running, so dropping the callback-owned reference in the waiter can free the lower transport before xstlshandshakedone() stores xprterr or drops its own reference.

If cancellation loses to completion, wait until xstlshandshakedone() signals handshakedone and let the callback release its reference. This mirrors the server-side handshake lifetime handling and keeps the timeout or signal return value unchanged.

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

svcrdma: Reject inline replies that overflow the pull-up buffer

An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svcrdmapullupneeded() selects pull-up and svcrdmapullupreplymsg() linearizes the whole reply into sctxt->scxprtbuf. That buffer is only scmaxreqsize bytes, while the reply on this path is bounded only by the client's request, so svcrdmaxblinearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in scsges[0].length and posted, so the device also reads beyond the mapped region.

The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMAPULLUPTHRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svcrdmapullupneeded() report -E2BIG when the reply it would pull up cannot fit scmaxreqsize, and fail the request with ERRCHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection.

The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svcrdmapullupneeded() to svcrdmacheckpullup() so its name no longer implies a boolean predicate.

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

lockd: pin next file across nlminspectfile lock-drop

nlmtraversefiles() pins the current file with fcount++ across a mutexunlock for nlminspectfile(), but nothing pins the saved next pointer. A concurrent nlmreleasefile() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step.

Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock.

Always call nlmfilerelease() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlmfileinuse(), which does a live walk of the inode lock list, rather than the cached flocks field, so skipped files that never ran nlminspectfile() are evaluated correctly.

Because every file in a hash bucket is now pinned and released, files skipped by the isfailoverfile predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.

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

sctp: stop processing a packet once its association is deleted

sctpendpointbhrcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference.

A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctpsfdo92final(), so the association and its transports are freed.

The endpoint loop has no counterpart to the asoc->base.dead check in sctpassocbhrcv(). The next chunk writes to lasttimeheard in the freed transport and is then passed to sctpdosm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context.

The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctpinqfree() releases the chunk on the association receive path.

sctpsfdo524dupcook() issues SCTPCMDDELETETCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.

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

crypto: iaa - unmap dst before software fallback on decompress

On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMAFROMDEVICE. With SWIOTLB active the later dmaunmapsg() copies the stale bounce buffer over req->dst, corrupting the result.

Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaacompadecompress() runs the fallback after unmapping.

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

ipv6: seg6: clear IPv4 control block on IPIP decapsulation

End.DX4 and End.DT4 decapsulate an IPv4 packet through decapandvalidate() and send it directly to IPv4 routing. The inner packet therefore bypasses iprcvcore(), which normally clears IPCB before IPv4 interprets skb->cb.

The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts.

The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6destoptrcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40.

Both tcpv4saveoptions() and ipoptionsecho() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls ipoptionsecho(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so ipoptionsecho() copies 255 bytes into the 40-byte option-data area.

Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced:

BUG: KASAN: slab-out-of-bounds in ipoptionsecho() Write of size 255

The relevant End.DX4 call path is:

ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddx4finish inputactionenddx4

The relevant End.DT4 call path is:

ipoptionsecho tcpv4routereq tcpconnrequest tcpv4connrequest tcprcvstateprocess tcpv4dorcv tcpv4rcv ipprotocoldeliverrcu iplocaldeliverfinish iplocaldeliver inputactionenddt4

tcpv4saveoptions() is inlined into the tcpv4routereq() path, so it does not appear as a separate frame.

When decapandvalidate() handles IPPROTOIPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm.

Use IP6CB(skb)->iif rather than skb->skbiif. These actions run after l3mdev processing, which can replace skbiif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.

dmaengine: idxd: fix double free of wq, engine, and group structs

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

scsi: hisisas: Add slavedestroy interface for v3 hw

WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log:

WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 devicelinksnodriver+0xb4/0xc0 Call trace: devicelinksnodriver+0xb4/0xc0 devicelinksdrivercleanup+0xb0/0xfc devicereleasedriver+0x198/0x23c devicereleasedriver+0x38/0x50 busremovedevice+0x130/0x140 devicedel+0x184/0x434 scsiremovedevice+0x118/0x150 scsiremovetarget+0x1bc/0x240 sasrphyremove+0x90/0x94 sasrphydelete+0x24/0x3c sasdestructdevices+0x64/0xa0 [libsas] sasrevalidatedomain+0xe4/0x150 [libsas] processonework+0x1e0/0x46c workerthread+0x15c/0x464 kthread+0x160/0x170 retfromfork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]---

During SAS phy up, link->status is set to DLSTATEAVAILABLE in devicelinksdriverbound, then this setting influences devicelinksnodriver() before driver rmmod and caused WARNING.

Add the slavedestroy interface to make sure link is removed after flush workque.

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

tracing/probes: Remove WARNONONCE from parsebtfarg

Sashiko found that user can cause this WARNONONCE() easily with adding a kprobe event based on a raw address with BTF parameter.

Since this is not an unexpected condition, remove the WARNONONCE().

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

dibs: initialise dibs->lock in dibsdevalloc()

dibs->lock is initialised by dibsdevadd(), but a dibs device can already take interrupts before that call: ismprobe() runs ismdevinit(), and hence requestirq(), before it calls dibsdevadd(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ismhandleirq() takes dibs->lock unconditionally on entry, before it inspects anything else.

Initialise the lock in dibsdevalloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.

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

ip6tunnel: clear skb2->cb[] in ip6ip6err()

ip6ip6err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6send(). The clone still carries the outer packet's inet6skbparm in skb->cb.

If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skbpull(). icmpv6send() later calls mip6addrswap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skbsharedinfo.

Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.

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

sctp: keep chunk->transport in step with the list it is queued on

sctpoutqflushrtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport:

if (chunk->tsngapacked) { listmovetail(&chunk->transmittedlist, &transport->transmitted); continue; }

The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. sctpassocrmpeer() scrubs peer->transmitted and asoc->outqueue.outchunklist, but the chunk is on neither.

The pointer is not followed while tsngapacked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches

tchunk->transport->flightsize -= sctpdatasize(tchunk);

inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer(). Both the removal and the SACKs come from the association peer.

Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its listmovetail() only after sctppacketappendchunk() returned SCTPXMITOK, and sctppacketappendchunk() has rebound the chunk by then.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

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:

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:

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:

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:

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:

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.

ata: satadwc460ex: enable SATA interrupts only after IRQ handler is registered