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

netfs: Fix missing barriers when accessing stream->subrequests locklessly

The list of subrequests attached to stream->subrequests is accessed without locks by netfscollectreadresults() and netfscollectwriteresults(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFSSREQINPROGRESS flag is perceived to be set first if no lock is taken.

Fix this by:

(1) Add a new listaddtailrelease() function that uses a release barrier to set the pointer to the new member of the list.

(2) Add a new listfirstentryornullacquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL).

(3) Use listaddtailrelease() when adding a subreq to ->subrequests.

(4) Use listfirstentryornullacquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).

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:

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

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

net: qrtr: fix refcount saturation and potential UAF in qrtrportremove

In qrtrportremove(), the socket reference count is decremented via sockput() before the port is removed from the qrtrports XArray and before the RCU grace period elapses.

This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtrresetports() or qrtrportlookup()) can obtain a pointer to the socket from the XArray, and attempt to call sockhold() on a socket whose reference count has already dropped to zero.

This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free:

refcountt: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcountwarnsaturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drmshmemhelper ... Call Trace: <TASK> qrtrresetports net/qrtr/afqrtr.c:768 [inline] [qrtr] qrtrbind.isra.0+0x48b/0x570 net/qrtr/afqrtr.c:805 [qrtr] qrtrbind+0x17d/0x210 net/qrtr/afqrtr.c:901 [qrtr] kernelbind+0xe4/0x120 net/socket.c:3592 qrtrnsinit+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtrprotoinit+0x3b/0xff0 net/qrtr/afqrtr.c:169 [qrtr] dooneinitcall+0xf5/0x5e0 init/main.c:1283 ... </TASK>

Fix this by deferring the reference count decrement until after the xaerase() and the synchronizercu() complete.

(Note: The v1 of this patch incorrectly replaced sockput() with sockput(). As Simon Horman pointed out, the callers of qrtrportremove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the sockput() is kept, but only repositioned to close the RCU race.)

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

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

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

smb/client: fix out-of-bounds read in symlinkdata()

Since smb2checkmessage() returns success without length validation for the symlink error response, in symlinkdata() it is possible for iov->iovlen to be smaller than sizeof(struct smb2errrsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlinkdata() will cause an out-of-bounds read.

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

mptcp: pm: ADDADDR rtx: fix potential data-race

This mptcppmaddtimer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bhlocksock().

If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.

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

ipv6: rpl: reserve maclen headroom when recompressed SRH grows

ipv6rplsrhrcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskbexpandhead() was gated on segmentsleft == 0, so on earlier segments the push consumed unchecked headroom. Once skbpush() leaves fewer than skb->maclen bytes in front of data, skbmacheaderrebuild()'s call to:

skbsetmacheader(skb, -skb->maclen);

will store (data - head) - maclen into the u16 macheader field, which wraps to ~65530, and the following memmove() writes maclen bytes ~64KiB past skb->head.

A single AFINET6/SOCKRAW/IPV6HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6rthdrrcv.

Fix this by expanding the head whenever the remaining room is less than the push size plus maclen, and request that much extra so the rebuilt MAC header fits afterwards.

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

wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled

When the TLC notification disables AMSDU for a TID, the MLD driver sets maxtidamsdulen to the sentinel value 1. The TSO segmentation path in iwlmldtxtsosegment() checks for zero but not for this sentinel, allowing it to reach the numsubframes calculation:

numsubframes = (maxtidamsdulen + pad) / (subflen + pad) = (1 + 2) / (1534 + 2) = 0

This zero propagates to iwltxtsosegment() which sets:

gsosize = numsubframes mss = 0

Calling skbgsosegment() with gsosize=0 creates over 32000 tiny segments from a single GSO skb. This floods the TX ring with ~1024 micro-frames (the rest are purged), creating a massive burst of TX completion events that can lead to memory corruption and a subsequent use-after-free in TCP's retransmit queue (refcount underflow in tcpshiftedskb, NULL deref in tcprackdetectloss).

The MVM driver is immune because it checks mvmsta->amsduenabled before reaching the numsubframes calculation. The MLD driver has no equivalent bitmap check and relies solely on maxtidamsdulen, which does not catch the sentinel value.

Fix this by detecting the sentinel value (maxtidamsdulen == 1) at the existing check and falling back to non-AMSDU TSO segmentation. Also add a WARNONONCE guard after the numsubframes division as defense-in-depth to catch any future code paths that produce zero through a different mechanism.

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:

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:

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:

bpf, skmsg: fix verdict skdataready racing with ktls rx

skpsockstrpdataready() already checks tlsswhasctxrx() and defers to psock->saveddataready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running skskb program types with ktls").

skpsockverdictdataready() has no equivalent guard. When a socket is inserted into a sockmap (BPFSKSKBVERDICT) before TLS RX is configured, tlsswstrparserarm() saves skpsockverdictdataready as rxctx->saveddataready. On data arrival:

tlsdataready -> tlsstrpdataready -> tlsrxmsgready -> saveddataready() = skpsockverdictdataready() -> tcpreadskb() drains skreceivequeue via skbunlink() without calling tcpeatskb(), so copiedseq is not advanced.

tlsstrpmsgload() then finds tcpinq() >= fulllen (stale), calls tcprecvskb() on the now-empty queue, hits WARNONONCE(!first), and returns with rxctx->strp.anchor.fraglist pointing at a psock-owned (potentially freed) skb. tlsdecryptsg() subsequently walks that fraglist: use-after-free.

Apply the same fix as skpsockstrpdataready(): if a TLS RX context is present, call psock->saveddataready (sockdefreadable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tlsswrecvmsg().

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

tcp: fix stale per-CPU tcptwisn leak enabling ISN prediction

Blamed commit moved the TIMEWAIT-derived ISN from the skb control block to a per-CPU variable, assuming the value would always be consumed by tcpconnrequest() for the same packet that wrote it. That assumption is violated by multiple drop paths between the producer (thiscpuwrite(tcptwisn, isn) in tcpv{4,6}rcv()) and the consumer (tcpconnrequest()):

- minttl / minhopcount check - xfrm policy check - tcpinboundhash() MD5/AO mismatch - tcpfilter() eBPF/SOATTACHFILTER drop - th->syn && th->fin discard in tcprcvstateprocess() TCPLISTEN - pspskrxpolicycheck() in tcpv{4,6}dorcv() - tcpchecksumcomplete() in tcpv{4,6}dorcv() - tcpv{4,6}cookiecheck() returning NULL

When a packet is dropped on any of these paths, tcptwisn is left set.

The next SYN processed on the same CPU then consumes the non zero value in tcpconnrequest(), receiving a potentially predictable ISN.

This patch moves back tcptwisn to skb->cb[], getting rid of the per-cpu variable.

Note that tcpv{4,6}fillcb() do not set it.

Very litle impact on overall code size/complexity:

$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) Function old new delta tcpv6rcv 3038 3042 +4 tcpv4rcv 3035 3039 +4 tcpconnrequest 2938 2923 -15 Total: Before=24436060, After=24436053, chg -0.00%

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

net: mana: validate rxreqidx to prevent out-of-bounds array access

In manahwcrxeventhandler(), rxreqidx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rxreqidx, which can lead to an out-of-bounds access into reqs[].

Add bounds check on rxreqidx in manahwcrxeventhandler() before using it to index the reqs[] array.

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

ksmbd: fix durable reconnect error path file lifetime

After a durable reconnect succeeds, ksmbdreopendurablefd() republishes the same ksmbdfile into the session volatile-id table. If smb2open() then takes a later error path, cleanup first calls ksmbdfdput(work, fp) and then unconditionally calls ksmbdputdurablefd(dhinfo.fp).

In this case fp and dhinfo.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run ksmbdclosefd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table.

Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dhinfo.fp, keep using the durable-only put path.

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:

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:

netfs: Fix potential for tearing in ->remoteisize and ->zeropoint

Fix potential tearing in using ->remoteisize and ->zeropoint by copying isizeread() and isizewrite() and using the same seqcount as for isize.

We need to make sure that netfslib and the filesystems that use it always hold ilock whilst updating any of the sizes to prevent isizeseqcount from getting corrupted.

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

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:

ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE

FSCTLSETSPARSE in fsctlsetsparse() modifies the file's sparse attribute and saves it through xattr without any permission checks.

This exposes two issues:

1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check testtreeconnflag(work->tcon, KSMBDTREECONNFLAGWRITABLE), but FSCTLSETSPARSE does not.

2) Even on writable shares, clients without FILEWRITEDATA or FILEWRITEATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here.

Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.

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

netfs: Fix missing locking around retry adding new subreqs

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

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

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:

netfs: Fix cancellation of a DIO and single read subrequests

When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works.

Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps:

(1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it.

(2) Make all three call netfsqueueread() to do the queuing.

(3) Set NETFSRREQALLQUEUED independently of the queuing as we don't know the length of the subreq at this point.

(4) In all cases, set the error and NETFSSREQFAILED flag on the subreq and then call netfsreadsubreqterminated() to deal with it. This will pass responsibility off to the collector for dealing with it.