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

nvme: nvme-fc: Ensure ->ioerrwork is cancelled in nvmefcdeletectrl()

nvmefcdeleteassocation() waits for pending I/O to complete before returning, and an error can cause ->ioerrwork to be queued after cancelworksync() had been called. Move the call to cancelworksync() to be after nvmefcdeleteassociation() to ensure ->ioerrwork is not running when the nvmefcctrl object is freed. Otherwise the following can occur:

[ 1135.911754] listdel corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/listdebug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:listdelentryvalidorreport.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.067540] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.071898] ? movelinkedworks+0x4a/0xa0 [ 1136.075998] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.081744] ? diebody.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? dotrap+0xca/0x110 [ 1136.091789] ? doerrortrap+0x65/0x80 [ 1136.095543] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.101289] ? excinvalidop+0x50/0x70 [ 1136.105127] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.110874] ? asmexcinvalidop+0x1a/0x20 [ 1136.115059] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.120806] movelinkedworks+0x4a/0xa0 [ 1136.124733] workerthread+0x216/0x3a0 [ 1136.128485] ? pfxworkerthread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? pfxkthread+0x10/0x10 [ 1136.139657] retfromfork+0x31/0x50 [ 1136.143236] ? pfxkthread+0x10/0x10 [ 1136.146988] retfromforkasm+0x1a/0x30 [ 1136.150915] </TASK>

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

eventfd double close

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

nfsd: fix nfs4openowner leak when concurrent nfsd4open occur

The action force umount(umount -f) will attempt to kill all rpctask even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpctask to nfs server.

NFS CLIENT thread1 thread2 open("file") ... nfs4doopen nfs4doopen nfs4openandgetstate nfs4procopen nfs4runopentask / rpctask1 / rpcruntask rpcwaitforcompletiontask

umount -f nfsumountbegin rpckillalltasks rpcsignaltask rpctask1 been wakeup and return -512 nfs4doopen // while loop ... nfs4runopentask / rpctask2 / rpcruntask rpcwaitforcompletiontask

While processing an open request, nfsd will first attempt to find or allocate an nfs4openowner. If it finds an nfs4openowner that is not marked as NFS4OOCONFIRMED, this nfs4openowner will released. Since two rpctask can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.

NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads

nfsd4open nfsd4processopen1 findorallocopenstateowner // alloc oo1, stateid1 nfsd4open nfsd4processopen1 findorallocopenstateowner // find oo1, without NFS4OOCONFIRMED releaseopenowner unhashopenownerlocked listdelinit(&oo->ooperclient) // cannot find this oo // from client, LEAK!!! allocstateowner // alloc oo2

nfsd4processopen2 initopenstateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4getvfsfile // alloc nfsdfile1 and nfsdfilemark1 // all LEAK!!!

nfsd4processopen2 ...

writethreads ... nfsddestroyserv nfsdshutdownnet nfs4stateshutdownnet nfs4statedestroynet destroyclient destroyclient // won't find oo1!!! nfsdshutdowngeneric nfsdfilecacheshutdown kmemcachedestroy for nfsdfileslab and nfsdfilemarkslab // bark since nfsdfile1 // and nfsdfilemark1 // still alive

======================================================================= BUG nfsdfile (Not tainted): Objects remaining in nfsdfile on kmemcacheshutdown() -----------------------------------------------------------------------

Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---

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

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().

The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.

This causes problems such as:

dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMAAPIDEBUG enabled:

DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().

Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

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:

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:

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:

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:

smb/client: fix out-of-bounds read in symlinkdata()

Since smb2checkmessage() returns success without length validation for the symlink error response, in symlinkdata() it is possible for iov->iovlen to be smaller than sizeof(struct smb2errrsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlinkdata() will cause an out-of-bounds read.

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:

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.

Issue summary: Calling the OpenSSL API function SSLselectnextproto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.

gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4CONNMSGLEN is not sufficient for a trailing '\0' character.

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

SUNRPC: Fix loop termination condition in gssfreeintokenpages()

The intoken->pages[] array is not NULL terminated. This results in the following KASAN splat:

KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]

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

ksmbd: fix out-of-bounds write in smb2getea() EA alignment

smb2getea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buffreelen is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space.

When the EA value exactly fills the remaining buffer (buffreelen == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buffreelen boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERYINFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory.

Add a bounds check before the alignment memset to ensure buffreelen can accommodate the padding bytes.

This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in getfileallinfo() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERYINFO for compound requests"), both of which added bounds checks before unconditional writes in QUERYINFO response handlers.

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

bridge: brndsend: linearize skb before parsing ND options

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

wifi: wilc1000: fix RCU usage in connect path

With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning:

============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcudereferencecheck() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpasupplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x48 dumpstacklvl from wilcparsejoinbssparam+0x7dc/0x7f4 wilcparsejoinbssparam from connect+0x2c4/0x648 connect from cfg80211connect+0x30c/0xb74 cfg80211connect from nl80211connect+0x860/0xa94 nl80211connect from genlrcvmsg+0x3fc/0x59c genlrcvmsg from netlinkrcvskb+0xd0/0x1f8 netlinkrcvskb from genlrcv+0x2c/0x3c genlrcv from netlinkunicast+0x3b0/0x550 netlinkunicast from netlinksendmsg+0x368/0x688 netlinksendmsg from syssendmsg+0x190/0x430 syssendmsg from syssendmsg+0x110/0x158 syssendmsg from syssendmsg+0xe8/0x150 syssendmsg from retfastsyscall+0x0/0x1c

This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilcparsejoinbssparam under the critical section, just use the critical section to copy ies data

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:

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.