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:

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.

batman-adv: v: stop OGMv2 on disabled interface

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

batman-adv: fix tpmeter counter underflow during shutdown

batman-adv: tvlv: reject oversized TVLV packets

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

batman-adv: tpmeter: avoid use of uninit sender vars

batman-adv: dat: handle forward allocation error

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:

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:

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

inet: frags: fix use-after-free caused by the fqdirpreexit() flush

On netns teardown, fqdirpreexit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inetfragqueueflush(). That helper frees all the skbs queued on the fragment queue but does not set INETFRAGCOMPLETE, and leaves q->fragmentstail and q->lastrunhead pointing at the freed skbs. The queue itself stays in the rhashtable.

fqdirpreexit() first lowers highthresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inetfragfind() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INETFRAGCOMPLETE check and then dereferences the freed fragmentstail. inetfragqueueinsert() reads FRAGCB() and ->len of that pointer and, on the append path, writes ->nextfrag, causing a slab use-after-free. IPv6, nfconntrackreasm6 and 6lowpan reassembly share the same flush path and are affected as well.

Reset rbfragments, fragmentstail and lastrunhead in inetfragqueueflush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragmentstail. ipfragreinit() already performed this reset after its own flush, so drop the now duplicate code there.

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

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:

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

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

net: rds: clear isends on setup unwind

The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released.

When rdsibsetupqp() fails after allocating isends but before allocating irecvs, the sendsout path frees isends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation.

Clear isends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.

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

xfrm: iptfs: preserve shared-frag marker in iptfsconsumefrags()

iptfsconsumefrags() transfers paged fragments from one socket buffer to another but fails to propagate the SKBFLSHAREDFRAG flag. This is the same class of bug that was fixed in skbtrycoalesce() for CVE-2026-46300: when fragments backed by read-only page-cache pages are merged, the marker indicating their shared nature must be preserved so that ESP can decide correctly whether in-place encryption is safe.

Apply the same two-line fix used in skbtrycoalesce() to iptfsconsumefrags().

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

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

net: tls: fix off-by-one in sgchain entry count for wrapped skmsg ring

When an skmsg scatterlist ring wraps (sg.end < sg.start), tlspushrecord() chains the tail portion of the ring to the head using sgchain(). An extra entry in the sg array is reserved for this:

struct skmsgsg { [...] / The extra two elements: 1) used for chaining the front and sections when the list becomes partitioned (e.g. end < start). The crypto APIs require the chaining; 2) to chain tailer SG entries after the message. / struct scatterlist data[MAXMSGFRAGS + 2];

The current code uses MAXSKBFRAGS + 1 as the ring size:

sgchain(&msgpl->sg.data[msgpl->sg.start], MAXSKBFRAGS - msgpl->sg.start + 1, msgpl->sg.data);

This places the chain pointer at

sgchain(data[start], (MAXSKBFRAGS - msgstart + 1) .. = &data[start] + (MAXSKBFRAGS - msgstart + 1) - 1 = data[start + (MAXSKBFRAGS - start + 1) - 1] = data[MAXSKBFRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: skmsg, zap ingress queue on psock down")

Convert to ARRAYSIZE and drop the data[start] / - start (as suggested by Sabrina).

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 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:

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.