In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix slab-use-after-free in inetlookupestablished
The ehash table lookups are lockless and rely on SLABTYPESAFEBYRCU to guarantee socket memory stability during RCU read-side critical sections. Both tcpprot and tcpv6prot have their slab caches created with this flag via protoregister().
However, MPTCP's mptcpsubflowinit() copies tcpv6prot into tcpv6protoverride during inetinit() (fsinitcall, level 5), before inet6init() (moduleinit/deviceinitcall, level 6) has called protoregister(&tcpv6prot). At that point, tcpv6prot.slab is still NULL, so tcpv6protoverride.slab remains NULL permanently.
This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLABTYPESAFEBYRCU, so when these sockets are freed without SOCKRCUFREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcureadlock can then access freed memory, triggering a slab-use-after-free in inetlookupestablished.
Fix this by splitting the IPv6-specific initialization out of mptcpsubflowinit() into a new mptcpsubflowv6init(), called from mptcpprotov6init() before protocol registration. This ensures tcpv6protoverride.slab correctly inherits the SLABTYPESAFEBYRCU slab cache.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix integer underflow in chain mode
The jumbofrm() chain-mode implementation unconditionally computes
len = nopagedlen - bmax;
where nopagedlen = skbheadlen(skb) (linear bytes only) and bmax is BUFSIZE8KiB or BUFSIZE2KiB. However, the caller stmmacxmit() decides to invoke jumbofrm() based on skb->len (total length including page fragments):
isjumbo = stmmacisjumbofrm(priv, skb->len, enhdesc);
When a packet has a small linear portion (nopagedlen <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax i pointers far beyond the skb buffer to dmamapsingle(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware.
Fix this by introducing a buflen local variable clamped to min(nopagedlen, bmax). Computing len = nopagedlen - buflen is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmacxmit() handles page fragments afterward.
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix use-after-free in -EBUSY error path of tlsdoencryption
The -EBUSY handling in tlsdoencryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encryptpending and the scatterlist entry.
When cryptoaeadencrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tlsencryptdone() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encryptpending. However, if tlsencryptasyncwait() returns an error, the synchronous error path in tlsdoencryption() performs the same cleanup again, double-decrementing encryptpending and double-restoring the scatterlist.
The double-decrement corrupts the encryptpending sentinel (initialized to 1), making tlsencryptasyncwait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tlsrec via bpfexectxverdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.
Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encryptpending and sge restoration.
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: ioam6: prevent schema length wraparound in trace fill
ioam6filltracedata() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. ioam6filltracedata() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer.
Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.
In the Linux kernel, the following vulnerability has been resolved:
net: ioam6: fix OOB and missing lock
When trace->type.bit6 is set:
if (trace->type.bit6) { ... queue = skbgettxqueue(dev, skb); qdisc = rcudereference(queue->qdisc);
This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettxqueue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.
While at it, add missing lock around qdiscqstatsqlenbacklog(). The function ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6teui64: reject invalid MAC header for all packets
eui64mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.
The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64mt6() can still reach ethhdr(skb) even when the MAC header is not valid.
Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing ethhdr(skb).
In the Linux kernel, the following vulnerability has been resolved:
seg6: separate dstcache for input and output paths in seg6 lwtunnel
The seg6 lwtunnel uses a single dstcache per encap route, shared between seg6inputcore() and seg6outputcore(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.
Fix this by splitting the cache into cacheinput and cacheoutput, so each path maintains its own cached dst independently.
batman-adv: reject oversized global TT response buffers
batman-adv: hold claim backbone gateways by reference
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: reject undecryptable rxkad response tickets
rxkaddecryptticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether cryptoskcipherdecrypt() succeeded.
A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes.
Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix RESPONSE authenticator parser OOB read
rxgkverifyauthenticator() copies authlen bytes into a temporary buffer and then passes p + authlen as the parser limit to rxgkdoverifyauthenticator(). Since p is a be32 , that inflates the parser end pointer by a factor of four and lets malformed RESPONSE authenticators read past the kmalloc() buffer.
Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:
BUG: KASAN: slab-out-of-bounds in rxgkverifyresponse() Call Trace: dumpstacklvl() [lib/dumpstack.c:123] printreport() [mm/kasan/report.c:379 mm/kasan/report.c:482] kasanreport() [mm/kasan/report.c:597] rxgkverifyresponse() [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]
Allocated by task 54: rxgkverifyresponse() [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386]
Convert the byte count to be32 units before constructing the parser limit.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix integer overflow in rxgkverifyresponse()
In rxgkverifyresponse(), there's a potential integer overflow due to rounding up tokenlen before checking it, thereby allowing the length check to be bypassed.
Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet).
In the Linux kernel, the following vulnerability has been resolved:
net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path
cppi5hdescgetpsdata() returns a pointer into the CPPI descriptor. In both emacrxpacket() and emacrxpacketzc(), the descriptor is freed via k3cppidescpoolfree() before the psdata pointer is used by emacrxtimestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path.
Defer the descriptor free until after all accesses through the psdata pointer are complete. For emacrxpacket(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emacrxpacketzc(), move the free to the end of the loop body after emacdispatchskbzc() (which calls emacrxtimestamp()) has returned.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: replace hardcoded hdr2len with offsetof() in smb2calcmaxoutbuflen()
After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2calcmaxoutbuflen() expects the second argument (hdr2len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free of shareconf in compound request
smb2getksmbdtcon() reuses work->tcon in compound requests without validating tcon->tstate. ksmbdtreeconnlookup() checks tstate == TREECONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely.
If a prior command in the compound (SMB2TREEDISCONNECT) sets tstate to TREEDISCONNECTED and frees shareconf via ksmbdshareconfigput(), subsequent commands dereference the freed shareconf through work->tcon->shareconf.
KASAN report:
[ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 4.145875] Workqueue: ksmbd-io handleksmbdwork [ 4.145888] Call Trace: [ 4.145892] <TASK> [ 4.145894] dumpstacklvl+0x64/0x80 [ 4.145910] printreport+0xce/0x660 [ 4.145919] ? pfxrawspinlockirqsave+0x10/0x10 [ 4.145928] ? smb2write+0xc74/0xe70 [ 4.145931] kasanreport+0xce/0x100 [ 4.145934] ? smb2write+0xc74/0xe70 [ 4.145937] smb2write+0xc74/0xe70 [ 4.145939] ? pfxsmb2write+0x10/0x10 [ 4.145942] ? rawspinunlock+0xe/0x30 [ 4.145945] ? ksmbdsmb2checkmessage+0xeb2/0x24c0 [ 4.145948] ? smb2treedisconnect+0x31c/0x480 [ 4.145951] handleksmbdwork+0x40f/0x1080 [ 4.145953] processonework+0x5fa/0xef0 [ 4.145962] ? assignwork+0x122/0x3e0 [ 4.145964] workerthread+0x54b/0xf70 [ 4.145967] ? pfxworkerthread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalcsigpending+0x19b/0x230 [ 4.145980] ? pfxkthread+0x10/0x10 [ 4.145984] retfromfork+0x4fb/0x6c0 [ 4.145992] ? pfxretfromfork+0x10/0x10 [ 4.145995] ? switchto+0x36c/0xbe0 [ 4.145999] ? pfxkthread+0x10/0x10 [ 4.146003] retfromforkasm+0x1a/0x30 [ 4.146013] </TASK> [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasansavestack+0x33/0x60 [ 4.150061] kasansavetrack+0x14/0x30 [ 4.150169] kasankmalloc+0x8f/0xa0 [ 4.150274] ksmbdshareconfigget+0x1dd/0xdd0 [ 4.150401] ksmbdtreeconnconnect+0x7e/0x600 [ 4.150529] smb2treeconnect+0x2e6/0x1000 [ 4.150645] handleksmbdwork+0x40f/0x1080 [ 4.150761] processonework+0x5fa/0xef0 [ 4.150873] workerthread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] retfromfork+0x4fb/0x6c0 [ 4.151176] retfromforkasm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasansavestack+0x33/0x60 [ 4.151526] kasansavetrack+0x14/0x30 [ 4.151634] kasansavefreeinfo+0x3b/0x60 [ 4.151751] kasanslabfree+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] ksmbdtreeconndisconnect+0xc8/0x190 [ 4.152088] smb2treedisconnect+0x1cd/0x480 [ 4.152211] handleksmbdwork+0x40f/0x1080 [ 4.152326] processonework+0x5fa/0xef0 [ 4.152438] workerthread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] retfromfork+0x4fb/0x6c0 [ 4.152743] retfromforkasm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in durable v2 replay of active file handles
parsedurablehandlecontext() unconditionally assigns dhinfo->fp->conn to the current connection when handling a DURABLEREQV2 context with SMB2FLAGSREPLAYOPERATION. ksmbdlookupfdcguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, ksmbdclosefd() dereferences the stale fp->conn via spinlock(&fp->conn->llistlock), causing a use-after-free.
KASAN report:
[ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in rawspinlock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 7.350070] Workqueue: ksmbd-io handleksmbdwork [ 7.350083] Call Trace: [ 7.350087] <TASK> [ 7.350087] dumpstacklvl+0x64/0x80 [ 7.350094] printreport+0xce/0x660 [ 7.350100] ? pfxrawspinlockirqsave+0x10/0x10 [ 7.350101] ? pfxmodtimer+0x10/0x10 [ 7.350106] ? rawspinlock+0x75/0xe0 [ 7.350108] kasanreport+0xce/0x100 [ 7.350109] ? rawspinlock+0x75/0xe0 [ 7.350114] kasancheckrange+0x105/0x1b0 [ 7.350116] rawspinlock+0x75/0xe0 [ 7.350118] ? pfxrawspinlock+0x10/0x10 [ 7.350119] ? callrcucommon.constprop.0+0x25e/0x780 [ 7.350125] ? closeiddeloplock+0x2cc/0x4e0 [ 7.350128] ksmbdclosefd+0x27f/0xaf0 [ 7.350131] ksmbdclosefd+0x135/0x1b0 [ 7.350133] smb2close+0xb19/0x15b0 [ 7.350142] ? pfxsmb2close+0x10/0x10 [ 7.350143] ? xasload+0x18/0x270 [ 7.350146] ? rawspinlock+0x84/0xe0 [ 7.350148] ? pfxrawspinlock+0x10/0x10 [ 7.350150] ? rawspinunlock+0xe/0x30 [ 7.350151] ? ksmbdsmb2checkmessage+0xeb2/0x24c0 [ 7.350153] ? ksmbdtreeconnlookup+0xcd/0xf0 [ 7.350154] handleksmbdwork+0x40f/0x1080 [ 7.350156] processonework+0x5fa/0xef0 [ 7.350162] ? assignwork+0x122/0x3e0 [ 7.350163] workerthread+0x54b/0xf70 [ 7.350165] ? pfxworkerthread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalcsigpending+0x19b/0x230 [ 7.350176] ? pfxkthread+0x10/0x10 [ 7.350178] retfromfork+0x4fb/0x6c0 [ 7.350183] ? pfxretfromfork+0x10/0x10 [ 7.350185] ? switchto+0x36c/0xbe0 [ 7.350188] ? pfxkthread+0x10/0x10 [ 7.350190] retfromforkasm+0x1a/0x30 [ 7.350197] </TASK> [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasansavestack+0x33/0x60 [ 7.355373] kasansavetrack+0x14/0x30 [ 7.355484] kasankmalloc+0x8f/0xa0 [ 7.355593] ksmbdconnalloc+0x44/0x6d0 [ 7.355711] ksmbdkthreadfn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] retfromfork+0x4fb/0x6c0 [ 7.356051] retfromforkasm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasansavestack+0x33/0x60 [ 7.356416] kasansavetrack+0x14/0x30 [ 7.356527] kasansavefreeinfo+0x3b/0x60 [ 7.356646] kasanslabfree+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbdtcpdisconnect+0x59/0xe0 [ 7.356993] ksmbdconnhandlerloop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] retfromfork+0x4fb/0x6c0 [ 7.357350] retfromforkasm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---
Bluetooth: L2CAP: Fix accepting multiple L2CAPECREDCONNREQ