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:

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:

netfilter: nftsetpipapoavx2: don't return non-matching entry on expiry

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo.

This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

We successfully re-inserted a . b c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching element only considering the first field,

i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nftpipapoavx2lookupslow' fallback.

Bisection points to 7711f4bb4b36 ("netfilter: nftsetpipapo: fix range overlap detection") but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.

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

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

netfilter: nfnetlinkosf: fix out-of-bounds read on option matching

In nfosfmatch(), the nfosfhdrctx structure is initialized once and passed by reference to nfosfmatchone() for each fingerprint checked. During TCP option parsing, nfosfmatchone() advances the shared ctx->optp pointer.

If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NFOSFLOGLEVELALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nfosfmatchone() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches.

Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nfosfmatchone() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.

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:

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentryhashtable when user sets 'dhashentries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:dlookup+0x56/0x120 Call Trace: dlookup.cold+0x16/0x5d lookupdcache+0x27/0xf0 lookuponeqstrexcl+0x2a/0x180 startdirop+0x55/0xa0 simplestartcreating+0x8d/0xa0 debugfsstartcreating+0x8c/0x180 debugfscreatedir+0x1d/0x1c0 pinctrlinit+0x6d/0x140 dooneinitcall+0x6d/0x3d0 kernelinitfreeable+0x39f/0x460 kernelinit+0x2a/0x260

There will be only one bucket in dentryhashtable when dhashentries is set as one, and dhashshift is calculated as 32 by dcacheinit(). Then, following process will access more than one buckets(which memory region is not allocated) in dentryhashtable: dlookup b = dhash(hash) dentryhashtable + ((u32)hashlen >> dhashshift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> dhashshift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlistblforeachentryrcu(b) hlistblfirstrcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentryhashtable bucket to two, so that 'dhashshift' won't exceeds the bit width of type u32.

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:

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); }

bridge: brndsend: linearize skb before parsing ND options

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.

ext4: avoid infinite loops caused by residual data

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

netfilter: nfconntrackexpect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfcthelp() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nfconntrackexpect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.

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:

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:

net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()

Syzkaller reported a panic in smctcpsynrecvsock() [1].

smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().

This leads to two issues:

1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriafops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheckreq() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) / No lock on listener / smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!

Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.

Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.

- Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcureadlock(). - Use rcureadlock() to protect reading skuserdata. - Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smcsock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smcsock field, so it is not affected.

Reproducer was verified with mdelay injection and smcrun, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

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

ip6gre: make ip6greheader() robust

Over the years, syzbot found many ways to crash the kernel in ip6greheader() [1].

This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheaderlen

In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ip6gre device.

[1] skbuff: skbunderpanic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ip6greheader+0xc8/0x790 net/ipv6/ip6gre.c:1371 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 neighoutput include/net/neighbour.h:556 [inline] ip6finishoutput2+0xfb3/0x1480 net/ipv6/ip6output.c:136 ip6finishoutput net/ipv6/ip6output.c:-1 [inline] ip6finishoutput+0x234/0x7d0 net/ipv6/ip6output.c:220 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693

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

net: stmmac: fix the crash issue for zero copy XDPTX action

There is a crash issue when running zero copy XDPTX action, the crash log is shown below.

[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcachecleanpoc+0x20/0x38 (P) [ 216.308308] dmasyncsinglefordevice+0x1bc/0x1e0 [ 216.313351] stmmacxdpxmitxdpf+0x354/0x400 [ 216.317701] stmmacxdprunprog+0x164/0x368 [ 216.322139] stmmacnapipollrxtx+0xba8/0xf00 [ 216.326576] napipoll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt

For XDPTX action, the xdpbuff is converted to xdpframe by xdpconvertbufftoframe(). The memory type of the resulting xdpframe depends on the memory type of the xdpbuff. For page pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEPOOL. For zero copy XSK pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEORDER0. However, stmmacxdpxmitback() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdpbuff memory type in stmmacxdpxmitback() to fix this issue.

bpf: Scrub packet on bpfredirectpeer

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcreleasegetacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? pfxsvcprocesscommon+0x10/0x10 ? rcureadunlock+0x69/0xa0 ? pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.

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

mptcp: consolidate suboption status

MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.

Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.

The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:

BUG: KMSAN: uninit-value in mptcpexpandseq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcpexpandseq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ackupdatemsk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 mptcpexpandseq net/mptcp/options.c:1030 [inline] mptcpexpandseq net/mptcp/protocol.h:864 [inline] ackupdatemsk net/mptcp/options.c:1060 [inline] mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 tcpdataqueue+0xb4/0x7be0 net/ipv4/tcpinput.c:5233 tcprcvestablished+0x1061/0x2510 net/ipv4/tcpinput.c:6264 tcpv4dorcv+0x7f3/0x11a0 net/ipv4/tcpipv4.c:1916 tcpv4rcv+0x51df/0x5750 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x2a3/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:460 [inline] iprcvfinish+0x4a2/0x520 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0xcd/0x380 net/ipv4/ipinput.c:567 netifreceiveskbonecore net/core/dev.c:5704 [inline] netifreceiveskb+0x319/0xa00 net/core/dev.c:5817 processbacklog+0x4ad/0xa50 net/core/dev.c:6149 napipoll+0xe7/0x980 net/core/dev.c:6902 napipoll net/core/dev.c:6971 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:7093 handlesoftirqs+0x1a0/0x7c0 kernel/softirq.c:561 dosoftirq+0x14/0x1a kernel/softirq.c:595 dosoftirq+0x9a/0x100 kernel/softirq.c:462 localbhenableip+0x9f/0xb0 kernel/softirq.c:389 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] devqueuexmit+0x2758/0x57d0 net/core/dev.c:4493 devqueuexmit include/linux/netdevice.h:3168 [inline] neighhhoutput include/net/neighbour.h:523 [inline] neighoutput include/net/neighbour.h:537 [inline] ipfinishoutput2+0x187c/0x1b70 net/ipv4/ipoutput.c:236 ipfinishoutput+0x287/0x810 ipfinishoutput+0x4b/0x600 net/ipv4/ipoutput.c:324 NFHOOKCOND include/linux/netfilter.h:303 [inline] ipoutput+0x15f/0x3f0 net/ipv4/ipoutput.c:434 dstoutput include/net/dst.h:450 [inline] iplocalout net/ipv4/ipoutput.c:130 [inline] ipqueuexmit+0x1f2a/0x20d0 net/ipv4/ipoutput.c:536 ipqueuexmit+0x60/0x80 net/ipv4/ipoutput.c:550 tcptransmitskb+0x3cea/0x4900 net/ipv4/tcpoutput.c:1468 tcptransmitskb net/ipv4/tcpoutput.c:1486 [inline] tcpwritexmit+0x3b90/0x9070 net/ipv4/tcpoutput.c:2829 tcppushpendingframes+0xc4/0x380 net/ipv4/tcpoutput.c:3012 tcpsendfin+0x9f6/0xf50 net/ipv4/tcpoutput.c:3618 tcpclose+0x140c/0x1550 net/ipv4/tcp.c:3130 mptcpclosessk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcpclosessk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcppmnlrmaddrorsubflow+0x635/0xd10 net/mptcp/pmnetlink.c:889 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:924 [inline] mptcppmflushaddrsandsubflows net/mptcp/pmnetlink.c:1688 [inline] mptcpnlflushaddrslist net/mptcp/pmnetlink.c:1709 [inline] mptcppmnlflushaddrsdoit+0xe10/0x1630 net/mptcp/pmnetlink.c:1750 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] ---truncated---

9p/net: fix improper handling of bogus negative read/write replies

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

smb: client: fix double-free in SMB2flush() replay

SMB2flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifssendrecv() stores a replacement response, flushexit will free the stale response pointer a second time.

Reinitialize respbuftype and rspiov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.

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

smb: client: fix change notify replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2notifyinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

smb: client: fix double-free in SMB2ioctl() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

smb: client: fix queryinfo() replay double-free

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2queryinfoinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.