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

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

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

net/handshake: Drain pending requests at net namespace exit

The arguments to listspliceinit() in handshakenetexit() are reversed. The call moves the local empty "requests" list onto hn->hnrequests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshakereq allocation.

Pass the source and destination in the documented order (listspliceinit(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshakecomplete().

Fixing the splice direction exposes a list-corruption race. After the splice each req->hrlist still has non-empty link pointers, threading the stack-local scratch list rather than hnrequests. A concurrent handshakereqcancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls removepending(), and sees !listempty(&req->hrlist). removependinglocked() then listdelinit()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run listdel() on an entry hits LISTPOISON instead.

Have removepending() check HANDSHAKEFNETDRAINING under hnlock and report not-found when drain is in progress. The drain has already taken ownership; handshakecomplete()'s existing testandset on HANDSHAKEFREQCOMPLETED still arbitrates between drain and cancel for who calls the consumer's hpdone. Use listdelinit() rather than listdel() in the drain so req->hrlist does not carry LISTPOISON after drain releases the entry.

The DRAINING guard in removepending() makes cancel return false, but cancel still falls through to testandsetbit on HANDSHAKEFREQCOMPLETED and drops the request's hrfile reference. Without another pin, if that is the last reference, skdestruct frees the request while it is still linked on the drain loop's local list. Pin each request's hrfile under hnlock before releasing the list, and drop that drain pin after the loop finishes with the request.

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

net/handshake: hand off the pinned file reference to acceptdoit

handshakereqnext() removes the request from the per-net pending list and drops hnlock before handshakenlacceptdoit() reads req->hrsk->sksocket and dereferences sock->file (once in FDPREPARE() and again in getfile()). In that window a consumer running tlshandshakecancel() followed by sockfdput() (svcsockfree) or fputsync() (xsresettransport) releases sock->file. sockrelease() then runs sockorphan(), zeroing sksocket, and frees the struct socket. The accept-side code either reads NULL through sksocket or chases freed memory.

The submit-side sockhold() does not prevent this. skrefcnt protects struct sock, but struct socket and sock->file are independently refcounted via the file descriptor the consumer owns. Pinning sk leaves sock and sock->file unprotected.

Retarget the accept-side dereferences at req->hrfile, which was pinned at submit time, instead of req->hrsk->sksocket->file. Pinning on its own is not sufficient: a consumer that cancels between handshakereqnext() returning and acceptdoit reaching FDPREPARE() takes the !removepending() branch in handshakereqcancel() and drops hrfile before the accept side takes its own reference. Hand off an additional file reference inside handshakereqnext(), under hnlock, so the accept side operates on a reference that no concurrent handshakereqcancel() can revoke. FDPREPARE() consumes that handed-off reference, either by transferring it to the new fd in fdpublish() or by dropping it in the cleanup destructor on error; the explicit getfile() that previously balanced FDPREPARE() is therefore redundant and goes away.

Update handshakereqcanceltest2 and test3 to simulate the FDPREPARE() consumption with an fput() so the kunit file-count assertions stay balanced.

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

KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use

As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests rely on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer.

Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information.

setupvmgexitscratch() allocates a buffer via kvzalloc(exitinfo2), where exitinfo2 is guest-controlled. With exitinfo2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte pschdr followed by 8-byte pscentry structs, so only entries[0] and entries[1] are in-bounds.

snpbeginpsc() validates endentry against VMGEXITPSCMAXCOUNT (253) but NOT against the actual buffer size:

idxend = hdr->endentry;

if (idxend >= VMGEXITPSCMAXCOUNT) { // checks 253, not buffer snpcompletepsc(svm, ...); return 1; }

for (idx = idxstart; idx <= idxend; idx++) { entrystart = entries[idx]; // OOB when idx >= 2

The guest sets endentry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry:

- The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, snpcompleteonepsc() writes curpage = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest)

The guest controls allocation size (exitinfo2), entry range (curentry/endentry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions.

By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write curpage bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs

E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports:

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199

The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)

Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free

All credit to Stan for the wonderful description and reproducer!

[sean: write changelog]

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.

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

scsi: target: iscsi: Bound iscsiencodetextoutput() appends to rspbuf

iscsiencodetextoutput() concatenates "key=value\0" records into login->rspbuf, an 8192-byte kzalloc(MAXKEYVALUEPAIRS) buffer allocated in iscsitallocloginsetupbuffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

length += sprintf(outputbuf, "%s=%s", er->key, er->value); length += 1; outputbuf = textbuf + length;

The 8192-byte ceiling at iscsitargetcheckloginrequest() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsiaddnotunderstoodresponse(). 2048 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsiencodetextrecord() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbufsize parameter through iscsiencodetextoutput(). Both call sites in iscsitargethandlecsgzero() (PHASESECURITY) and iscsitargethandlecsgone() (PHASEOPERATIONAL) pass MAXKEYVALUEPAIRS. On overflow the encoder logs the condition, calls iscsireleaseextraresponses() to drop queued records, and returns -1; both caller sites now emit ISCSISTATUSCLSINITIATORERR / ISCSILOGINSTATUSINITERR via iscsittxloginrsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASEOPERATIONAL caller did that; the PHASESECURITY caller is converted to the same shape.)

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

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

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

scsi: target: iscsi: Validate CHAPR length before base64 decode

chapservercomputehash() allocates clientdigest as kzalloc(chap->digestsize) and then, for BASE64-encoded responses, passes chapr directly to chapbase64decode() without checking whether the input length could produce more than digestsize bytes of output.

chapbase64decode() writes to the destination unconditionally as long as there is input to consume. With MAXRESPONSELENGTH set to 128 and the "0b" prefix stripped by extractparam(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digestsize=32) this overflows clientdigest by 63 bytes; for MD5 (digestsize=16) the overflow is 79 bytes.

The length check at line 344 fires after the write has already happened.

The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIVROUNDUP(digestsize 4, 3) before calling the decoder.

Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chapbase64decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.

The mutual CHAP path decodes CHAPC into initiatorchgbinhex, which is kzalloc(CHAPCHALLENGESTRLEN). extractparam() caps initiatorchg at CHAPCHALLENGESTRLEN characters, so at most CHAPCHALLENGESTRLEN-1 base64 characters reach the decoder. The maximum decoded size, DIVROUNDUP((CHAPCHALLENGESTRLEN-1) 3, 4), is less than CHAPCHALLENGESTRLEN, so no overflow is possible there. A comment is added at the call site to document this.

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

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

KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry

vgicitsinvalidatecache() walks the per-ITS translation cache with xaforeach() and drops the cache's reference on each entry with vgicputirq(). It puts the iterated pointer, though, rather than the value returned by xaerase().

The function is called from contexts that do not exclude one another: the ITS command handlers hold itslock, the GITSCTLR write path holds cmdlock, and the path that clears EnableLPIs in a redistributor's GICRCTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it.

xaerase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer.

The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the max size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert).

Opportunistically rename @len => @minlen to better reflect its role.

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

KVM: SEV: Use READONCE() when reading entries/indices from PSC buffer

Use READONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs.

Don't bother with READONCE()/WRITEONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READONCE() is all about protecting against misbehaving guests.

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

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

net: airoha: Fix use-after-free in metadata dst teardown

airohametadatadstfree() runs metadatadstfree() which frees the metadatadst with kfree() immediately, bypassing the RCU grace period. In the RX path, skbdstsetnoref() sets a non-refcounted pointer from the skb to the metadatadst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadatadstfree() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadatadstfree() with dstrelease() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via callrcuhurry(), ensuring all RCU readers have completed before the memory is freed.

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

net: phy: clean the sfp upstream if phy probing fails

Sashiko reported that we don't call sfpbusdelupstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events.

This issue existed before the generic phylib sfp support, back when drivers were calling physfpprobe themselves.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

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

RDMA/srp: bound SRPRSP sense copy by the received length

srpprocessrsp() copies sense data from rsp->data + respdatalen, where respdatalen is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->bytelen). The copy length is bounded to SCSISENSEBUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.

A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRPRSP with SRPRSPFLAGSNSVALID set and a large respdatalen. The receive buffer is allocated at the target-chosen maxtiiulen, so the source of the sense copy lands past the bytes actually received; with respdatalen near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.

Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->bytelen; this brings ibsrp into line with them.

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

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

ksmbd: fix use-after-free of a deferred filelock on double SMB2CANCEL

A deferred byte-range lock (an SMB2LOCK that blocks) registers an async work on conn->asyncrequests via setupasyncwork(), with cancelfn = smb2removeblockedlock and cancelargv[0] pointing at the struct filelock.

When the request is cancelled, the worker frees the filelock with locksfreelock() and takes the cancelled early-exit, which "goto out"s and never reaches releaseasyncwork() -- the only site that unlinks the work from conn->asyncrequests and clears cancelfn/cancelargv. The work therefore stays matchable on asyncrequests with a live cancelfn pointing at the freed filelock, until connection teardown finally runs releaseasyncwork().

smb2cancel() fires cancelfn unconditionally with no state guard, so a second SMB2CANCEL for the same AsyncId, arriving in that window, re-runs smb2removeblockedlock() on the freed filelock -- a slab use-after-free:

BUG: KASAN: slab-use-after-free in locksdeleteblock locksdeleteblock locksdeleteblock ksmbdvfsposixlockunblock smb2removeblockedlock smb2cancel <- 2nd SMB2CANCEL fires cancelfn handleksmbdwork Allocated by ...: locksalloclock <- smb2lock Freed by ...: locksfreelock <- smb2lock (cancelled branch) ... cache filelockcache of size 192

Reproduced on mainline with KASAN by an authenticated SMB client.

Skip a work whose state is already KSMBDWORKCANCELLED so its cancel callback cannot be fired a second time.

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

net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmaclist

mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mclist capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:

BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385

CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>

Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.

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

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

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

ip6vti: set netnsimmutable on the fallback device.

john1988 and Noam Rathaus reported that vti6initnet() does not set the netnsimmutable flag on the per-netns fallback tunnel device (ip6vti0).

Other similar tunnel drivers (like ip6tunnel, sit, ip6gre, and iptunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.

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

RDMA: During reregmr ensure that REREGACCESS is compatible

If IBMRREREGACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ibumemcheckrereg() function that each driver has to call before processing IBMRREREGACCESS.

mlx4 has to retain its duplicate ibaccesswritable check because it implements IBMRREREGACCESS | IBMRREREGTRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.

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

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

misc: fastrpc: fix DMA address corruption due to findvma misuse

fastrpcgetargs() uses findvma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGEMASK) - vma->vmstart underflows, corrupting the DMA address sent to the DSP.

Replace findvma() with vmalookup(), which returns NULL when the address is not contained within any VMA.

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

accel/ethosu: fix arithmetic issues in dmalength()

dmalength() derives DMA region usage from command stream values and updates regionsize[]:

len = ((len + stride[0]) size0 + stride[1]) size1 regionsize[region] = max(..., len + dma->offset)

Several arithmetic issues can corrupt the derived region size:

- signed stride values may underflow when added to len - intermediate multiplications may overflow - len + dma->offset may overflow during regionsize updates - dmalength() error returns were not validated by the caller

regionsize[] is later used by ethosujob.c to validate command stream accesses against GEM buffer sizes. Arithmetic wraparound can therefore under-report region usage and bypass the bounds validation.

Fix by validating signed additions, using overflow helpers for multiplications and offset updates, and propagating dmalength() failures to the caller.