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

ksmbd: fix use-after-free in ksmbdclosefd() via durable scavenger

When a durable file handle survives session disconnect (TCP close without SMB2LOGOFF), sessionfdcheck() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->locklist.

Later, when the durable scavenger thread times out and calls ksmbdclosefd(NULL, fp), the lock cleanup loop did:

spinlock(&fp->conn->llistlock);

This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbdtcpdisconnect().

The root cause is asymmetric cleanup: lock entries (smblock->clist) were left dangling on the freed conn->locklist while fp->conn was nulled out.

To fix this issue properly, we need to handle the lifetime of smblock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's locklist in sessionfdcheck() - Re-add the lock to the new connection's locklist in ksmbdreopendurablefd().

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:

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:

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmettcphandleicreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under statelock.

If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMETTCPQFAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with statelock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmettcpsocketerror() setting rcvstate to NVMETTCPRECVERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

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:

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:

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().