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

netfilter: socket: Lookup orig tuple for IPv6 SNAT

nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.

However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.

IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.

bus: mhi: ep: Update read pointer only after buffer is written

9p: avoid putting oldfid in p9clientwalk() error path

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

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

ksmbd: fix integer overflows on 32 bit systems

On 32bit systems the addition operations in ipcmsgalloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBDIPCMAXPAYLOAD to avoid overflow.

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:

RDMA/rtrs: Add missing deinit() call

A warning is triggered when repeatedly connecting and disconnecting the rnbd: listadd corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340). WARNING: CPU: 1 PID: 36562 at lib/listdebug.c:32 listaddvalidorreport+0x7f/0xa0 Workqueue: ibcm cmworkhandler [ibcm] RIP: 0010:listaddvalidorreport+0x7f/0xa0 ? listaddvalidorreport+0x7f/0xa0 ibregistereventhandler+0x65/0x93 [ibcore] rtrssrvibdevinit+0x29/0x30 [rtrsserver] rtrsibdevfindoradd+0x124/0x1d0 [rtrscore] allocpath+0x46c/0x680 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] ? rcuiswatching+0xd/0x40 ? mutexlock+0x312/0xcf0 ? getorcreatesrv+0xad/0x310 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] rtrsrdmaconnect+0x23c/0x2d0 [rtrsserver] ? lockrelease+0x1b1/0x2d0 cmacmeventhandler+0x4a/0x1a0 [rdmacm] cmaibreqhandler+0x3a0/0x7e0 [rdmacm] cmprocesswork+0x28/0x1a0 [ibcm] ? rawspinunlockirq+0x2f/0x50 cmreqhandler+0x618/0xa60 [ibcm] cmworkhandler+0x71/0x520 [ibcm]

Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a new element .deinit but never used it at all. Fix it by invoking the deinit() to appropriately unregister the IB event handler.

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

RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.

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

nvmet: Fix crash when a namespace is disabled

The namespace percpu counter protects pending I/O, and we can only safely diable the namespace once the counter drop to zero. Otherwise we end up with a crash when running blktests/nvme/058 (eg for loop transport):

[ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Tainted: [W]=WARN [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvmeloopexecutework [nvmeloop] [ 2352.930449] [ T53909] RIP: 0010:blkcgsetioprio+0x44/0x180

as the queue is already torn down when calling submitbio();

So we need to init the percpu counter in nvmetnsenable(), and wait for it to drop to zero in nvmetnsdisable() to avoid having I/O pending after the namespace has been disabled.

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

nvme-tcp: fix potential memory corruption in nvmetcprecvpdu()

nvmetcprecvpdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvmetcpverifyhdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.

Fix this by rejecting packets with an unexpected header length.

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

netmem: prevent TX of unreadable skbs

Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it.

Fix this by preventing the xmit of unreadable skbs.

Tested by configuring tc redirect:

sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ipproto \ tcp srcip 192.168.1.12 action mirred egress redirect dev eth1

Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs.

After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs.

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

fs/netfs/readcollect: add to next->prevdonated

If multiple subrequests donate data to the same "next" request (depending on the subrequest completion order), each of them would overwrite the prevdonated field, causing data corruption and a BUG() crash ("Can't donate prior to front").

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

RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()

After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.

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

Revert "smb: client: fix TCP timers deadlock after rmmod"

This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.

Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0]

Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket.

When a reconnect happens for a CIFS connection, the socket state transitions to FINWAIT1. Then, inetcskclearxmittimerssync() in tcpclose() stops all timers for the socket.

If an incoming FIN packet is lost, the socket will stay at FINWAIT1 forever, and such sockets could be leaked up to net.ipv4.tcpmaxorphans.

Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.

I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged.

So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sknetrefcnt is 0.

The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it.

For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.

However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.

If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.

Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.

That's why I converted the CIFS client socket to have a reference to netns (sk->sknetrefcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but is in-scope and right fix.

Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in socklockinitclassandname(). [2]

For a while, let's revert the bogus fix.

Note that now we can use sknetrefcntupgrade() for the socket conversion, but I'll do so later separately to make backport easy.

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

smb: client: fix UAF in decryption with multichannel

After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption.

This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,maxchannels=4,seal' against Windows Server 2022:

BUG: KASAN: slab-use-after-free in gf128mul4klle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 printreport+0x156/0x528 ? gf128mul4klle+0xba/0x110 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? gf128mul4klle+0xba/0x110 kasanreport+0xdf/0x1a0 ? gf128mul4klle+0xba/0x110 gf128mul4klle+0xba/0x110 ghashupdate+0x189/0x210 shashahashupdate+0x295/0x370 ? pfxshashahashupdate+0x10/0x10 ? pfxshashahashupdate+0x10/0x10 ? pfxextractitertosg+0x10/0x10 ? kmalloclargenode+0x10e/0x180 ? asanmemset+0x23/0x50 cryptoahashupdate+0x3c/0xc0 gcmhashassocremaincontinue+0x93/0xc0 cryptmessage+0xe09/0xec0 [cifs] ? pfxcryptmessage+0x10/0x10 [cifs] ? rawspinunlock+0x23/0x40 ? pfxcifsreadvfromsocket+0x10/0x10 [cifs] decryptrawdata+0x229/0x380 [cifs] ? pfxdecryptrawdata+0x10/0x10 [cifs] ? pfxcifsreaditerfromsocket+0x10/0x10 [cifs] smb3receivetransform+0x837/0xc80 [cifs] ? pfxsmb3receivetransform+0x10/0x10 [cifs] ? pfxmightresched+0x10/0x10 ? pfxsmb3istransformhdr+0x10/0x10 [cifs] cifsdemultiplexthread+0x692/0x1570 [cifs] ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? rculockdepcurrentcpuonline+0x62/0xb0 ? findheldlock+0x32/0x90 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xd/0xd0 ? traceirqenable.constprop.0+0xa8/0xe0 ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? pfxkthread+0x10/0x10 ? localclocknoinstr+0xd/0xd0 ? retfromfork+0x1b/0x60 ? localclock+0x15/0x30 ? lockrelease+0x29b/0x390 ? rcuiswatching+0x20/0x50 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

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

ksmbd: Fix dangling pointer in krbauthenticate

krbauthenticate frees sess->user and does not set the pointer to NULL. It calls ksmbdkrb5authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2sesssetup, which calls krbauthenticate, will be accessing free'd memory when it later uses sess->user.

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

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

net: ethernet: mtkethsoc: fix SER panic with 4GB+ RAM

If the mtkpollrx() function detects the MTKRESETTING flag, it will jump to releasedesc and refill the high word of the SDP on the 4GB RFB. Subsequently, mtkrxclean will process an incorrect SDP, leading to a panic.

Add patch from MediaTek's SDK to resolve this.

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

net: use sockgenput() when skstate is TCPTIMEWAIT

It is possible for a pointer of type struct inettimewaitsock to be returned from the functions inetlookupestablished() and inet6lookupestablished(). This can cause a crash when the returned pointer is of type struct inettimewaitsock and sockput() is called on it. The following is a crash call stack that shows sk->skwmemalloc being accessed in skfree() during the call to sockput() on a struct inettimewaitsock pointer. To avoid this issue, use sockgenput() instead of sockput() when sk->skstate is TCPTIMEWAIT.

mrdump.ko ipanic() + 120 vmlinux notifiercallchain(nrtocall=-1, nrcalls=0) + 132 vmlinux atomicnotifiercallchain(val=0) + 56 vmlinux panic() + 344 vmlinux addtaint() + 164 vmlinux endreport() + 136 vmlinux kasanreport(size=0) + 236 vmlinux reporttagfault() + 16 vmlinux dotagrecovery() + 16 vmlinux dokernelfault() + 88 vmlinux dobadarea() + 28 vmlinux dotagcheckfault() + 60 vmlinux domemabort() + 80 vmlinux el1abort() + 56 vmlinux el1h64synchandler() + 124 vmlinux > 0xFFFFFFC080011294() vmlinux lseatomicfetchaddrelease(v=0xF2FFFF82A896087C) vmlinux lseatomicfetchsubrelease(v=0xF2FFFF82A896087C) vmlinux archatomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux rawatomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux atomicfetchsubrelease(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux refcountsubandtest(i=1, r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcountdecandtest(r=0xF2FFFF82A896087C, oldp=0) + 8 vmlinux refcountdecandtest(r=0xF2FFFF82A896087C) + 8 vmlinux skfree(sk=0xF2FFFF82A8960700) + 28 vmlinux sockput() + 48 vmlinux tcp6checkfraglistgro() + 236 vmlinux tcp6groreceive() + 624 vmlinux ipv6groreceive() + 912 vmlinux devgroreceive() + 1116 vmlinux napigroreceive() + 196 ccmni.ko ccmnirxcallback() + 208 ccmni.ko ccmniqueuerecvskb() + 388 cccidpmaif.ko dpmaifrxqpushthread() + 1088 vmlinux kthread() + 268 vmlinux 0xFFFFFFC08001F30C()

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

ksmbd: fix use-after-free in kerberos authentication

Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbdfreeuser. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbdfreeuser but before sess->user is set to NULL.

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

scsi: target: iscsi: Fix timeout on deleted connection

NOPIN response timer may expire on a deleted connection and crash with such logs:

Did not receive response to NOPIN on CID: 0, failing connection for IT Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d

BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsitfillcxntimeouterrstats+0x5c/0xc0 [iscsitargetmod] Call Trace: iscsithandlenopinresponsetimeout+0xfc/0x120 [iscsitargetmod] calltimerfn+0x58/0x1f0 runtimersoftirq+0x740/0x860 dosoftirq+0x16c/0x420 irqexit+0x188/0x1c0 timerinterrupt+0x184/0x410

That is because nopin response timer may be re-started on nopin timer expiration.

Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.

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

sunrpc: handle SVCGARBAGE during svc auth processing as auth error

tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVCGARBAGE is returned without setting the rqacceptstatp pointer, then that pointer can be dereferenced and a value stored there.

If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble.

The server sunrpc code treats a SVCGARBAGE return from svcauthenticate or pgauthenticate as if it should send a GARBAGEARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTHERR.

Handle a SVCGARBAGE return as an AUTHERROR, with a reason of AUTHBADCRED instead of returning GARBAGEARGS in that case. This sidesteps the whole problem of touching the rpcacceptstatp pointer in this situation and avoids the crash.

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

netfs: Fix oops in write-retry from mis-resetting the subreq iterator

Fix the resetting of the subrequest iterator in netfsretrywritestream() to use the iterator-reset function as the iterator may have been shortened by a previous retry. In such a case, the amount of data to be written by the subrequest is not "subreq->len" but "subreq->len - subreq->transferred".

Without this, KASAN may see an error in ioviterrevert():

BUG: KASAN: slab-out-of-bounds in ioviterrevert lib/ioviter.c:633 [inline] BUG: KASAN: slab-out-of-bounds in ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147

CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: eventsunbound netfswritecollectionworker Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 ioviterrevert lib/ioviter.c:633 [inline] ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 netfsretrywritestream fs/netfs/writeretry.c:44 [inline] netfsretrywrites+0x166d/0x1a50 fs/netfs/writeretry.c:231 netfscollectwriteresults fs/netfs/writecollect.c:352 [inline] netfswritecollectionworker+0x23fd/0x3830 fs/netfs/writecollect.c:374 processonework+0x9cf/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

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

net: wwan: t7xx: Fix napi rx poll issue

When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic.

BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:devgroreceive+0x3a/0x620 [...] Call Trace: <IRQ> ? diebody+0x68/0xb0 ? pagefaultoops+0x379/0x3e0 ? excpagefault+0x4f/0xa0 ? asmexcpagefault+0x22/0x30 ? pfxt7xxccmnirecvskb+0x10/0x10 [mtkt7xx (HASH:1400 7)] ? devgroreceive+0x3a/0x620 napigroreceive+0xad/0x170 t7xxccmnirecvskb+0x48/0x70 [mtkt7xx (HASH:1400 7)] t7xxdpmaifnapirxpoll+0x590/0x800 [mtkt7xx (HASH:1400 7)] netrxaction+0x103/0x470 irqexitrcu+0x13a/0x310 sysvecapictimerinterrupt+0x56/0x90 </IRQ>

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

RDMA/iwcm: Fix use-after-free of work objects after cmid destruction

The commit 59c68ac31e15 ("iwcm: free cmid resources on the last deref") simplified cmid resource management by freeing cmid once all references to the cmid were removed. The references are removed either upon completion of iwcm event handlers or when the application destroys the cmid. This commit introduced the use-after-free condition where cmidprivate object could still be in use by event handler works during the destruction of cmid. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cmid destruction.

However, still another use-after-free possibility remained. It happens with the work objects allocated for each cmidpriv within allocworkentries() during cmid creation, and subsequently freed in deallocworkentries() once all references to the cmid are removed. If the cmid's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:

BUG: KASAN: slab-use-after-free in pwqactivatework+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iwcmwq) Call Trace: <TASK> dumpstacklvl+0x6a/0x90 printreport+0x174/0x554 ? virtaddrvalid+0x208/0x430 ? pwqactivatework+0x1ff/0x250 kasanreport+0xae/0x170 ? pwqactivatework+0x1ff/0x250 pwqactivatework+0x1ff/0x250 pwqdecnrinflight+0x8c5/0xfb0 processonework+0xc11/0x1460 ? pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5ef/0xfd0 ? pfxworkerthread+0x10/0x10 kthread+0x3b0/0x770 ? pfxkthread+0x10/0x10 ? rcuiswatching+0x11/0xb0 ? rawspinunlockirq+0x24/0x50 ? rcuiswatching+0x11/0xb0 ? pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 147416: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasankmalloc+0xa6/0xb0 allocworkentries+0xa9/0x260 [iwcm] iwcmconnect+0x23/0x4a0 [iwcm] rdmaconnectlocked+0xbfd/0x1920 [rdmacm] nvmerdmacmhandler+0x8e5/0x1b60 [nvmerdma] cmacmeventhandler+0xae/0x320 [rdmacm] cmaworkhandler+0x106/0x1b0 [rdmacm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Freed by task 147091: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 kasanslabfree+0x4b/0x70 kfree+0x13a/0x4b0 deallocworkentries+0x125/0x1f0 [iwcm] iwcmderefid+0x6f/0xa0 [iwcm] cmworkhandler+0x136/0x1ba0 [iwcm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x2c/0x50 kasanrecordauxstack+0xa3/0xb0 queuework+0x2ff/0x1390 queueworkon+0x67/0xc0 cmeventhandler+0x46a/0x820 [iwcm] siwcmupcall+0x330/0x650 [siw] siwcmworkhandler+0x6b9/0x2b20 [siw] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.

To avoid the use-after-free of cmidprivate work objects, ensure that the last reference to the cmid is decremented not in the event handler works, but in the cmid destruction context. For that purpose, mo ---truncated---

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

nvme-tcp: sanitize request list handling

Validate the request in nvmetcphandler2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.

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

bnxt: properly flush XDP redirect lists

We encountered following crash when testing a XDPREDIRECT feature in production:

[56251.579676] listadd corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/listdebug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARYMODULE, [O]=OOTMODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:listaddvalidorreport+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] <IRQ> [56251.851943] cpumapenqueue.cold+0x5/0xa [56251.860243] xdpdoredirect+0x2d9/0x480 [56251.868388] bnxtrxxdp+0x1d8/0x4c0 [bnxten] [56251.877028] bnxtrxpkt+0x5f7/0x19b0 [bnxten] [56251.885665] ? cpumaxwrite+0x1e/0x100 [56251.893510] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.902276] bnxtpollwork+0x190/0x340 [bnxten] [56251.911058] bnxtpoll+0xab/0x1b0 [bnxten] [56251.919041] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.927568] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.935958] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.944250] napipoll+0x2b/0x160 [56251.951155] bpftrampoline6442548651+0x79/0x123 [56251.959262] napipoll+0x5/0x160 [56251.966037] netrxaction+0x3d2/0x880 [56251.973133] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.981265] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.989262] ? hrtimerrunqueues+0x162/0x2a0 [56251.996967] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.004875] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.012673] ? bnxtmsix+0x62/0x70 [bnxten] [56252.019903] handlesoftirqs+0xcf/0x270 [56252.026650] irqexitrcu+0x67/0x90 [56252.032933] commoninterrupt+0x85/0xa0 [56252.039498] </IRQ> [56252.044246] <TASK> [56252.048935] asmcommoninterrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidleenterstate+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidleenterstate+0xab/0x420 [56252.153909] cpuidleenter+0x2d/0x40 [56252.160360] doidle+0x176/0x1c0 [56252.166456 ---truncated---

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

nfsd: nfsd4spomustallow() must check this is a v4 compound request

If the request being processed is not a v4 compound request, then examining the cstate can have undefined results.

This patch adds a check that the rpc procedure being executed (rqprocinfo) is the NFSPROC4COMPOUND procedure.

bnxten: Set DMA unmap len correctly for XDPREDIRECT

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

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.

BUG: KASAN: slab-use-after-free in tlsstrpcheckrcv+0x898/0x9a0 [tls] (net/tls/tlsstrp.c:436 net/tls/tlsstrp.c:530 net/tls/tlsstrp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529

CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasanreport+0xca/0x100 tlsstrpcheckrcv+0x898/0x9a0 [tls] tlsrxrecwait+0x2c9/0x8d0 [tls] tlsswrecvmsg+0x40f/0x1aa0 [tls] inetrecvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.fulllen").