In the Linux kernel, the following vulnerability has been resolved:
net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
emacdispatchskbzc() allocates a new skb via napiallocskb() but never copies the packet data from the XDP buffer into it. The skb is passed up the stack containing uninitialized heap memory instead of the actual received packet, leaking kernel heap contents to userspace.
Copy the received packet data from the XDP buffer into the skb using skbcopytolineardata().
Additionally, remove the skbmarkforrecycle() call since the skb is backed by the NAPI page frag allocator, not pagepool. Marking a non-pagepool skb for recycle causes the free path to return pages to a pagepool that does not own them, corrupting pagepool state.
The non-ZC path (emacrxpacket) does not have these issues because it uses napibuildskb() to wrap the existing pagepool page directly, requiring no copy, and correctly marks for recycle since the page comes from pagepooldevallocpages().
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Completely fix fcport double free
In qla24xxelsdcmdiocb() sp->free is set to qla2x00elsdcmdspfree(). When an error happens, this function is called by qla2x00sprelease(), when krefput() releases the first and the last reference.
qla2x00elsdcmdspfree() frees fcport by calling qla2x00freefcport(). Doing it one more time after krefput() is a bad idea.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ
XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.
The issue was discovered by the drivers/net/xdp.py selftest, more specifically the testxdpnativetxmb: - The mlx5 driver allocates a pagepool page and initializes it with a frag counter of 64 (pprefcount=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5eskbfromcqempwrqnonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpfxdppulldata() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pprefcount=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pprefcount is 63 => negative reference counting error.
Resulting splat during the test:
WARNING: CPU: 0 PID: 188225 at ./include/net/pagepool/helpers.h:297 mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7forupstreammindebug202512081144 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0xbd/0xe0 [mlx5core] [...] Call Trace: <TASK> mlx5efreerxmpwqe+0x20a/0x250 [mlx5core] mlx5edeallocrxmpwqe+0x37/0xb0 [mlx5core] mlx5efreerxdescs+0x11a/0x170 [mlx5core] mlx5ecloserq+0x78/0xa0 [mlx5core] mlx5eclosequeues+0x46/0x2a0 [mlx5core] mlx5eclosechannel+0x24/0x90 [mlx5core] mlx5eclosechannels+0x5d/0xf0 [mlx5core] mlx5esafeswitchparams+0x2ec/0x380 [mlx5core] mlx5echangemtu+0x11d/0x490 [mlx5core] mlx5echangenicmtu+0x19/0x30 [mlx5core] netifsetmtuext+0xfc/0x240 dosetlink.isra.0+0x226/0x1100 rtnlnewlink+0x7a9/0xba0 rtnetlinkrcvmsg+0x220/0x3c0 netlinkrcvskb+0x4b/0xf0 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendmsg+0x1e8/0x240 syssendmsg+0x7c/0xb0 [...] syssendmsg+0x5f/0xb0 dosyscall64+0x55/0xc70
The problem applies for XDPPASS as well which is handled in a different code path in the driver.
This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.
As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.
ext4: avoid infinite loops caused by residual data
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:
ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()
Sashiko AI-review observed:
In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6send(), it uses IP6CB(skb2).
IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.
If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLVHAO).
This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.
Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?
Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6err() to prevent this?
This patch implements the first suggestion.
I am not sure if ip6ip6err() needs to be changed. A separate patch would be better anyway.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Compare MACs in constant time
To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, cryptomemneq().
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUELIMIT).
When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.
This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.
We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.
Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rpbuflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.
In the Linux kernel, the following vulnerability has been resolved:
net/x25: Fix overflow when accumulating packets
Add a check to ensure that x25sock.fraglen does not overflow.
The fraglen also needs to be resetted when purging fragmentqueue in x25clearqueues().
In the Linux kernel, the following vulnerability has been resolved:
net/x25: Fix potential double free of skb
When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:
x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again
This would free the same skb twice. Looking at x25backlogrcv:
net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: clear skb2->cb[] in ip4ip6err()
Oskar Kjos reported the following problem.
ip4ip6err() calls icmpsend() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6skbparm. icmpsend() passes IPCB(skb2) to ipoptionsecho(), which interprets that cb[] region as struct inetskbparm (IPv4). The layouts differ: inet6skbparm.nhoff at offset 14 overlaps inetskbparm.opt.rr, producing a non-zero rr value. ipoptionsecho() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->data, a fixed 40-byte stack buffer (IPOPTIONSDATAFIXEDSIZE).
To fix this we clear skb2->cb[], as suggested by Oskar Kjos.
Also add minimal IPv4 header validation (version == 4, ihl >= 5).
bpf: Fix stack-out-of-bounds write in devmap
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Make kvmgetvcpubycpuid() more robust
kvmgetvcpubycpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvmgetvcpubycpuid() return NULL for this case so as to make it more robust.
This fix an out-of-bounds access to kvmarch::phyidmap::physmap[].
can: gw: fix OOB heap access in cgwcsumcrc8rel()
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:
iommupt: Fix short gather if the unmap goes into a large mapping
unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE.
In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition.
This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause.
As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.
In the Linux kernel, the following vulnerability has been resolved:
fs/smb/client: fix out-of-bounds read in cifssanitizeprepath
When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.
This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.
The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrackh323: check for zero length in DecodeQ931()
In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.
Add a check to ensure len is positive after the decrement.
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---
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: unset conn->binding on failed binding request
When a multichannel SMB2SESSIONSETUP request with SMB2SESSIONREQFLAGBINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbdsessionlookupall() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial OOB in getfileallinfo() for compound requests
When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix OOB write in QUERYINFO for compound requests
When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.
The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.
This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.
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: do not expire session on binding failure
When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2SESSIONEXPIRED. However, during binding, sess points to the target session looked up via ksmbdsessionlookupslowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS).
Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbdsessionlookupslowpath() is still correctly released via ksmbdusersessionput().
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix bcackers underflow on duplicate GRPACKMSG
The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.
Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.
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:
netfilter: nftables: always walk all pending catchall elements
During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch.
If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate.
Otherwise, we get: WARNING: ./include/net/netfilter/nftables.h:1281 at nftdatarelease+0xb7/0xe0 [nftables], CPU#2: nft/1404 RIP: 0010:nftdatarelease+0xb7/0xe0 [nftables] [..] nftsetelemdestroy+0x106/0x380 [nftables] nftablesabortrelease+0x348/0x8d0 [nftables] nftablesabort+0xcf2/0x3ac0 [nftables] nfnetlinkrcvbatch+0x9c9/0x20e0 [..]
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix use-after-free in ctnetlinkdumpexpct()
ctnetlinkdumpexpct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlinkexpctdumptable(), but drops the conntrack reference immediately after netlinkdumpstart(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfcthelp(ct), leading to a use-after-free on ct->ext.
The bug is that the netlinkdumpcontrol has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlinkgetconntrack) properly use .start/.done callbacks for this purpose.
Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfcthelp() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.
BUG: KASAN: slab-use-after-free in ctnetlinkexpctdumptable+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlinkpoc/133
CPU: 1 UID: 0 PID: 133 Comm: ctnetlinkpoc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlinkexpctdumptable+0x4f/0x2e0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 ? aaskperm+0x184/0x450 sockrecvmsg+0xde/0xf0
Allocated by task 133: kmemcacheallocnoprof+0x134/0x440 nfconntrackalloc+0xa8/0x2b0 ctnetlinkcreateconntrack+0xa1/0x900 ctnetlinknewconntrack+0x3cf/0x7d0 nfnetlinkrcvmsg+0x48e/0x510 netlinkrcvskb+0xc9/0x1f0 nfnetlinkrcv+0xdb/0x220 netlinkunicast+0x3ec/0x590 netlinksendmsg+0x397/0x690 syssendmsg+0xf4/0x180
Freed by task 0: slabfreeafterrcudebug+0xad/0x1e0 rcucore+0x5c3/0x9c0
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd
The /proc/fs/nfs/exports proc entry is created at module init and persists for the module's lifetime. exportsprocopen() captures the caller's current network namespace and stores its svcexportcache in seq->private, but takes no reference on the namespace. If the namespace is subsequently torn down (e.g. container destruction after the opener does setns() to a different namespace), nfsdnetexit() calls nfsdexportshutdown() which frees the cache. Subsequent reads on the still-open fd dereference the freed cachedetail, walking a freed hash table.
Hold a reference on the struct net for the lifetime of the open file descriptor. This prevents nfsdnetexit() from running -- and thus prevents nfsdexportshutdown() from freeing the cache -- while any exports fd is open. cachedetail already stores its net pointer (cd->net, set by cachecreatenet()), so exportsrelease() can retrieve it without additional per-file storage.