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:
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:
ksmbd: add freetransport ops in ksmbd connection
freetransport function for tcp connection can be called from smbdirect. It will cause kernel oops. This patch add freetransport ops in ksmbd connection, and add each freetransports for tcp and smbdirect.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix double put of request
If a netfs request finishes during the pause loop, it will have the ref that belongs to the INPROGRESS flag removed at that point - however, if it then goes to the final wait loop, that will also put the ref because it sees that the INPROGRESS flag is clear and incorrectly assumes that this happened when it called the collector.
In fact, since INPROGRESS is clear, we shouldn't call the collector again since it's done all the cleanup, such as calling ->kicomplete().
Fix this by making netfscollectinapp() just return, indicating that we're done if INPROGRESS is removed.
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").
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cryptmessage when using async crypto
The CVE-2024-50047 fix removed asynchronous crypto handling from cryptmessage(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:
cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);
// Async encryption returns -EINPROGRESS immediately rc = enc ? cryptoaeadencrypt(req) : cryptoaeaddecrypt(req);
// Free creq while async operation is still in progress kvfreesensitive(creq, ...);
Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.
This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.
The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.
Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowaitreq() to wait for operation completion
This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.
In the Linux kernel, the following vulnerability has been resolved:
rpl: Fix use-after-free in rpldosrhinline().
Running lwtdstcacherefloop.sh in selftest with KASAN triggers the splat below [0].
rpldosrhinline() fetches ipv6hdr(skb) and accesses it after skbcowhead(), which is illegal as the header could be freed then.
Let's fix it by making oldhdr to a local struct instead of a pointer.
[0]: [root@fedora net]# ./lwtdstcacherefloop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpldosrhinline.isra.0 (net/ipv6/rpliptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543
CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:122) printreport (mm/kasan/report.c:409 mm/kasan/report.c:521) kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:636) kasancheckrange (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) asanmemmove (mm/kasan/shadow.c:94 (discriminator 2)) rpldosrhinline.isra.0 (net/ipv6/rpliptunnel.c:174) rplinput (net/ipv6/rpliptunnel.c:201 net/ipv6/rpliptunnel.c:282) lwtunnelinput (net/core/lwtunnel.c:459) ipv6rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6input.c:311 (discriminator 1)) netifreceiveskbonecore (net/core/dev.c:5967) processbacklog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) napipoll.constprop.0 (net/core/dev.c:7452) netrxaction (net/core/dev.c:7518 net/core/dev.c:7643) handlesoftirqs (kernel/softirq.c:579) dosoftirq (kernel/softirq.c:480 (discriminator 20)) </IRQ> <TASK> localbhenableip (kernel/softirq.c:407) devqueuexmit (net/core/dev.c:4740) ip6finishoutput2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6output.c:141) ip6finishoutput (net/ipv6/ip6output.c:215 net/ipv6/ip6output.c:226) ip6output (./include/linux/netfilter.h:306 net/ipv6/ip6output.c:248) ip6sendskb (net/ipv6/ip6output.c:1983) rawv6sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) syssendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) x64syssendto (net/socket.c:2231) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 </TASK>
Allocated by task 1543: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) kasanslaballoc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmemcacheallocnodenoprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmallocreserve (net/core/skbuff.c:581 (discriminator 88)) allocskb (net/core/skbuff.c:669) ip6appenddata (net/ipv6/ip6output.c:1672 (discriminator 1)) ip6 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: remove duplicate pagepoolputfullpage()
pagepoolputfullpage() should only be invoked when freeing Rx buffers or building a skb if the size is too short. At other times, the pages need to be reused. So remove the redundant page put. In the original code, double free pages cause kernel panic:
[ 876.949834] irqexitrcu+0xc7/0x130 [ 876.949836] commoninterrupt+0xb8/0xd0 [ 876.949838] </IRQ> [ 876.949838] <TASK> [ 876.949840] asmcommoninterrupt+0x22/0x40 [ 876.949841] RIP: 0010:cpuidleenterstate+0xc2/0x420 [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246 [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000 [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580 [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000 [ 876.949852] ? cpuidleenterstate+0xb3/0x420 [ 876.949855] cpuidleenter+0x29/0x40 [ 876.949857] cpuidleidlecall+0xfd/0x170 [ 876.949859] doidle+0x7a/0xc0 [ 876.949861] cpustartupentry+0x25/0x30 [ 876.949862] startsecondary+0x117/0x140 [ 876.949864] commonstartup64+0x13e/0x148 [ 876.949867] </TASK> [ 876.949868] ---[ end trace 0000000000000000 ]--- [ 876.949869] ------------[ cut here ]------------ [ 876.949870] listdel corruption, ffffead40445a348->next is NULL [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/listdebug.c:52 listdelentryvalidorreport+0x67/0x120 [ 876.949875] Modules linked in: sndhrtimer(E) bnep(E) binfmtmisc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amdatl(E) sndhdacodecrealtek(E) intelraplmsr(E) sndhdacodecgeneric(E) intelraplcommon(E) sndhdascodeccomponent(E) sndhdacodechdmi(E) sndhdaintel(E) edacmceamd(E) sndinteldspcfg(E) sndhdacodec(E) sndhdacore(E) amdxcp(E) kvmamd(E) sndhwdep(E) gpusched(E) drmpanelbacklightquirks(E) cec(E) sndpcm(E) drmbuddy(E) sndseqdummy(E) drmttmhelper(E) btusb(E) kvm(E) sndseqoss(E) btrtl(E) ttm(E) btintel(E) sndseqmidi(E) btbcm(E) drmexec(E) sndseqmidievent(E) i2calgobit(E) sndrawmidi(E) bluetooth(E) drmsuballochelper(E) irqbypass(E) sndseq(E) ghashclmulniintel(E) sha512ssse3(E) drmdisplayhelper(E) aesniintel(E) sndseqdevice(E) rfkill(E) sndtimer(E) gf128mul(E) drmclientlib(E) drmkmshelper(E) snd(E) i2cpiix4(E) joydev(E) soundcore(E) wmibmof(E) ccp(E) k10temp(E) i2csmbus(E) gpioamdpt(E) i2cdesignwareplatform(E) gpiogeneric(E) sg(E) [ 876.949914] i2cdesignwarecore(E) schfqcodel(E) parportpc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) iptables(E) ext4 crc16 mbcache jbd2 sdmod sfp mdioi2c i2ccore txgbe ahci ngbe pcsxpcs libahci libwx r8169 phylink libata realtek ptp ppscore video wmi [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary) [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNEDMODULE [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 876.949936] RIP: 0010:listdelentryvalidorreport+0x67/0x120 [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8 [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282 [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000 [ 876.949942] RDX: 0000000000000105 RSI: 00000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrack: fix crash due to removal of uninitialised entry
A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: nfctdeletefromlists+172] [..] #7 [ff539b5a2b043aa0] nfctdelete at ffffffffc124d421 [nfconntrack] #8 [ff539b5a2b043ad0] nfctgcexpired at ffffffffc124d999 [nfconntrack] #9 [ff539b5a2b043ae0] nfconntrackfindget at ffffffffc124efbc [nfconntrack] [..]
The nfconn struct is marked as allocated from slab but appears to be in a partially initialised state:
ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPSCONFIRMED|IPSDYING, which is expected ct->timeout is 30000 (=30s), which is unexpected.
Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value.
If it were not for the presence of IPSCONFIRMED, nfconntrackfindget() would have skipped the entry.
Theory is that we did hit following race:
cpu x cpu y cpu z found entry E found entry E E is expired <preemption> nfctdelete() return E to rcu slab initconntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value.
cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit.
->refcnt set to 1 E now owned by skb ->timeout set to 30000
If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit.
nfconntrackconfirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable.
cpu y resumes, it observes E as expired but CONFIRMED: <resumes> nfctexpired() -> yes (ct->timeout is 30s) confirmed bit set.
cpu y will try to delete E from the hashtable: nfctdelete() -> set DYING bit nfctdeletefromlists
Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks:
wait for spinlock held by z
CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value.
unlocks spinlock return NFDROP <unblocks, then crashes on hlistnullsdelrcu pprev>
In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs.
Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nfconntrackput -> nfconntrackdestroy -> nfctdestroy.
To resolve this, move the IPSCONFIRMED assignment after the table insertion but before the unlock.
Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to setbit and beforeatomic memory barrier to prevent this.
It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set:
Such event cannot be distinguished from above "E is the old incarnation" case: the entry will be skipped.
Also change nfctshouldgc() to first check the confirmed bit.
The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nfctshouldgc() to double-check step 1.
nfctshouldgc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifsoplockbreak
A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:
cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: fix the using of Rx buffer DMA
The wxrxbuffer structure contained two DMA address fields: 'dma' and 'pagedma'. However, only 'pagedma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths.
This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ismcmd()
The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.
A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: plug races between subflow fail and subflow creation
We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.
The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.
The socket fallback makes such flag true, and also receiving or sending an MPFAIL option.
The field 'allowinfinitefallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.
btrfs: fix a race between renames and directory logging
In the Linux kernel, the following vulnerability has been resolved:
scsi: fnic: Fix crash in fnicwqcmplhandler when FDMI times out
When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash.
Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly.
Tested by checking MDS for FDMI information.
Tested by using instrumented driver to:
- Drop PLOGI response - Drop RHBA response - Drop RPA response - Drop RHBA and RPA response - Drop PLOGI response + ABTS response - Drop RHBA response + ABTS response - Drop RPA response + ABTS response - Drop RHBA and RPA response + ABTS response for both of them
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: fix crash in wacomaesbatteryhandler()
Commit fd2a9b29dc9c ("HID: wacom: Remove AES powersupply after extended inactivity") introduced wacomaesbatteryhandler() which is scheduled as a delayed work (aesbatterywork).
In wacomremove(), aesbatterywork is not canceled. Consequently, if the device is removed while aesbatterywork is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacomaesbatteryhandler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aesbatterywork was still pending at the time of hibernation.
So, take care to cancel aesbatterywork in wacomremove().
In the Linux kernel, the following vulnerability has been resolved:
rose: fix dangling neighbour pointers in rosertdevicedown()
There are two bugs in rosertdevicedown() that can cause use-after-free:
1. The loop bound t->count is modified within the loop, which can cause the loop to terminate early and miss some entries.
2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index i is still incremented, causing the next entry to be skipped.
For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked.
i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false)
This leaves the second A in the array with count=2, but the roseneigh structure has been freed. Code that accesses these entries assumes that the first count entries are valid pointers, causing a use-after-free when it accesses the dangling pointer.
Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Avoid overflow with array index
The variable index is modified and reused as array index when modify register EIOINTCENABLE. There will be array index overflow problem.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potential use-after-free in oplock/lease break ack
If ksmbdiovpinrsp return error, use-after-free can happen by accessing opinfo->state and opinfoput and ksmbdfdput could called twice.
HID: core: ensure the allocated report buffer can contain the reserved report ID
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pf: Clear all LMTT pages on alloc
Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.
Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.
While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.
(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
In the Linux kernel, the following vulnerability has been resolved:
wifi: prevent A-MSDU attacks in mesh networks
This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks.
This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt.
This defense was tested with mac80211hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field.
It was also tested with mac80211hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented.
Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation:
https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
In the Linux kernel, the following vulnerability has been resolved:
regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods
drvdata::gpiods is supposed to hold an array of 'gpiodesc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors.
While at it, also move the check for memory allocation failure to be below the allocation to make it more readable.
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: ensure the received length does not exceed allocated size
In xdplinearizepage, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: make fallback action and fallback decision atomic
Syzkaller reported the following splat:
WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netsched: prio: fix a race in priotune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root [2]: qdisctreeflushbacklog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisctreereducebacklog() | [4]: qdiscput()
This can be abused to underflow a parent's qlen.
Calling qdiscpurgequeue() instead of qdisctreeflushbacklog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.
In the Linux kernel, the following vulnerability has been resolved:
drivers/rapidio/riocm.c: prevent possible heap overwrite
In
riocmcdevioctl(RIOCMCHANSEND) -> cmchanmsgsend() -> riocmchsend()
cmchanmsgsend() checks that userspace didn't send too much data but riocmchsend() failed to check that userspace sent sufficient data. The result is that riocmchsend() can write to fields in the riochchanhdr which were outside the bounds of the space which cmchanmsgsend() allocated.
Address this by teaching riocmchsend() to check that the entire riochchanhdr was copied in from userspace.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in tapriodevnotifier
Since taprio’s tapriodevnotifier() isn’t protected by an RCU read-side critical section, a race with advancesched() can lead to a use-after-free.
Adding rcureadlock() inside tapriodevnotifier() prevents this.
Bluetooth: MGMT: Protect mgmtpending list with its own lock