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:

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.

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:

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:

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:

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:

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

bnxten: Set DMA unmap len correctly for XDPREDIRECT

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.

btrfs: fix a race between renames and directory logging

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:

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:

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.