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:

igc: set tx buffer type for SMD frames

Sashiko pointed out that igcfpeinitsmdframe() initializes igctxbuffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp

Since igctxbuffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path.

Set the buffer type to IGCTXBUFFERTYPESKB.

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

netfs: Fix netfsreadtopagecache() to pause on subreq failure

Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.

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

ipv6: ioam: refresh hdr pointer before ioam6event()

Reported by Sashiko:

In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:

if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;

/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));

ioam6filltracedata(skb, ns, trace, true);

ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);

If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.

This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.

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

net/mlx5e: Fix use-after-free in mlx5etxreportertimeoutrecover

mlx5etxreportertimeoutrecover() accesses sq->netdev after mlx5esafereopenchannels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown.

The netdeverr() call already used priv->netdev for this reason; make the trylock/unlock and healthchanneleqrecover calls consistent.

This fixes the following KASAN splat:

BUG: KASAN: use-after-free in mlx5etxreportertimeoutrecover+0x1dd/0x360 [mlx5core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277

Call Trace: mlx5etxreportertimeoutrecover+0x1dd/0x360 [mlx5core] devlinkhealthreporterrecover+0xa2/0x150 devlinkhealthreport+0x254/0x7c0 mlx5ereportertxtimeout+0x297/0x380 [mlx5core] mlx5etxtimeoutwork+0x109/0x170 [mlx5core] processonework+0x677/0xf20 workerthread+0x51f/0xd90 kthread+0x3a5/0x810 retfromfork+0x208/0x400 retfromforkasm+0x1a/0x30

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:

net: mana: Fix TOCTOU double-fetch of hwcmsgid from DMA buffer

In manahwcrxeventhandler(), resp->response.hwcmsgid is read from DMA-coherent memory and bounds-checked, then manahwchandleresp() re-reads the same field from the same DMA buffer for testbit() and pointer arithmetic.

DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation.

Fix this by reading hwcmsgid exactly once using READONCE() into a stack-local variable in manahwcrxeventhandler(), and passing the validated value as a parameter to manahwchandleresp().

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

firmware: armffa: Snapshot notifier callbacks under lock

Both notification handlers currently look up a notifier callback under notifylock, drop the lock, and then dereference the returned notifier entry. A concurrent unregister can delete and free that entry in the gap, leaving the handler to dereference stale memory.

Copy the callback pointer and callback data while notifylock is still held and invoke the callback only after the lock is dropped. This keeps the existing callback execution model while removing the use-after-free window in both the framework and non-framework notification paths.

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:

RDMA/rtrs: Fix use-after-free in path file creation cleanup

In the error path of rtrssrvcreatepathfiles(), the sysfs root folders may already have been created and srvpath->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobjectput(&srvpath->kobj) before rtrssrvdestroyoncesysfsrootfolders(srvpath).

kobjectput() may drop the last reference to srvpath->kobj and invoke the release callback, rtrssrvrelease(), which frees srvpath. The following call to rtrssrvdestroyoncesysfsrootfolders(srvpath) then dereferences srvpath internally to access srvpath->srv, resulting in a use-after-free.

This failure path is reached before rtrssrvcreatepathfiles() returns success, so the successful-path lifetime handling is not involved.

Fix this by destroying the sysfs root folders before calling kobjectput(&srvpath->kobj), so srvpath is still valid while the helper accesses it.

This issue was found by a static analysis tool I am developing.

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:

drm/msm: Fix iommumapsgtable() return value check and avoid WARN

Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.

Store the return value in the appropriate type and in case of error, return it rather than WARNing.

Patchwork: https://patchwork.freedesktop.org/patch/719685/

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

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.