In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: fix UaF read in mptcppmnlrmaddrorsubflow
Syzkaller reported this splat:
================================================================== BUG: KASAN: slab-use-after-free in mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662
CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:914 [inline] mptcpnlremoveidzeroaddress+0x305/0x4a0 net/mptcp/pmnetlink.c:1572 mptcppmnldeladdrdoit+0x5c9/0x770 net/mptcp/pmnetlink.c:1603 genlfamilyrcvmsgdoit+0x202/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x565/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x165/0x410 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x53c/0x7f0 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8b8/0xd70 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg net/socket.c:744 [inline] syssendmsg+0x9ae/0xb40 net/socket.c:2607 syssendmsg+0x135/0x1e0 net/socket.c:2661 syssendmsg+0x117/0x1f0 net/socket.c:2690 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0x73/0x120 arch/x86/entry/common.c:386 dofastsyscall32+0x32/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIGRAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>
Allocated by task 5387: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmallocnoprof include/linux/slab.h:878 [inline] kzallocnoprof include/linux/slab.h:1014 [inline] subflowcreatectx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflowulpinit+0xc3/0x4d0 net/mptcp/subflow.c:1956 tcpsetulp net/ipv4/tcpulp.c:146 [inline] tcpsetulp+0x326/0x7f0 net/ipv4/tcpulp.c:167 mptcpsubflowcreatesocket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 mptcpsubflowconnect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcppmcreatesubfloworsignaladdr+0xbda/0x23a0 net/mptcp/pmnetlink.c:642 mptcppmnlfullyestablished net/mptcp/pmnetlink.c:650 [inline] mptcppmnlwork+0x3a1/0x4f0 net/mptcp/pmnetlink.c:943 mptcpworker+0x15a/0x1240 net/mptcp/protocol.c:2777 processonework+0x958/0x1b30 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/ke ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix user-after-free from session log off
There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add sessionlock when setting SMB2SESSIONEXPIRED and referece count to session struct not to free session while it is being used.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix race between laundromat and freestateid
There is a race between laundromat handling of revoked delegations and a client sending freestateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing freestateid processing thread does the following (1) it calls listdelinit() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revokedelegation() function for this particular delegation but that means it will no release the lock lease that exists on the file.
Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsdbreakerownslease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning:
kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsdbreakerownslease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dumpbacktrace+0x98/0x120 kernel: showstack+0x1c/0x30 kernel: dumpstacklvl+0x80/0xe8 kernel: printaddressdescription.constprop.0+0x84/0x390 kernel: printreport+0xa4/0x268 kernel: kasanreport+0xb4/0xf8 kernel: asanreportload8noabort+0x1c/0x28 kernel: nfsdbreakerownslease+0x140/0x160 [nfsd] kernel: nfsdfiledoacquire+0xb3c/0x11d0 [nfsd] kernel: nfsdfileacquireopened+0x84/0x110 [nfsd] kernel: nfs4getvfsfile+0x634/0x958 [nfsd] kernel: nfsd4processopen2+0xa40/0x1a40 [nfsd] kernel: nfsd4open+0xa08/0xe80 [nfsd] kernel: nfsd4proccompound+0xb8c/0x2130 [nfsd] kernel: nfsddispatch+0x22c/0x718 [nfsd] kernel: svcprocesscommon+0x8e8/0x1960 [sunrpc] kernel: svcprocess+0x3d4/0x7e0 [sunrpc] kernel: svchandlexprt+0x828/0xe10 [sunrpc] kernel: svcrecv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: retfromfork+0x10/0x20
This patch proposes a fixed that's based on adding 2 new additional stid's scstatus values that help coordinate between the laundromat and other operations (nfsd4freestateid() and nfsd4delegreturn()).
First to make sure, that once the stid is marked revoked, it is not removed by the nfsd4freestateid(), the laundromat take a reference on the stateid. Then, coordinating whether the stid has been put on the clrevoked list or we are processing FREESTATEID and need to make sure to remove it from the list, each check that state and act accordingly. If laundromat has added to the clrevoke list before the arrival of FREESTATEID, then nfsd4freestateid() knows to remove it from the list. If nfsd4freestateid() finds that operations arrived before laundromat has placed it on clrevoke list, it marks the state freed and then laundromat will no longer add it to the list.
Also, for nfsd4delegreturn() when looking for the specified stid, we need to access stid that are marked removed or freeable, it means the laundromat has started processing it but hasn't finished and this delegreturn needs to return nfserrdelegrevoked and not nfserrbadstateid. The latter will not trigger a FREESTATEID and the lack of it will leave this stid on the clrevoked list indefinitely.
bpf: devmap: provide rxq after redirect
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix possible double free in smb2setea()
Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~
There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto seaexit' -> 'first memory release for ea' -> 'goto replayagain' -> 'second goto seaexit before allocate memory for ea' -> 'second memory release for ea resulted in double free'.
Re-initialie 'ea' to NULL near to the replayagain label, it can fix this double free problem.
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Don't use timerpending() in reqskqueueunlink().
Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler().
""" We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """
The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window.
Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending.
If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default.
The scenario would be
1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timerpending() by passing the caller context to inetcskreqskqueuedrop().
Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]
[0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtkethsoc: fix memory corruption during fq dma init
The loop responsible for allocating up to MTKFQDMALENGTH buffers must only touch as many descriptors, otherwise it ends up corrupting unrelated memory. Fix the loop iteration count accordingly.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in ksmbdsmb2sessioncreate
There is a race condition between ksmbdsmb2sessioncreate and ksmbdexpiresession. This patch add missing sessionstablelock while adding/deleting session from global session table.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in smb3preauthhashrsp
ksmbdusersessionput should be called under smb3preauthhashrsp(). It will avoid freeing session before calling smb3preauthhashrsp().
In the Linux kernel, the following vulnerability has been resolved:
net: vertexcom: mse102x: Fix possible double free of TX skb
The scope of the TX skb is wider than just mse102xtxframespi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102xtxwork(), which leads to crashes:
Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102xtxwork [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbreleasedata+0xb8/0x1d8 lr : skbreleasedata+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skbreleasedata+0xb8/0x1d8 kfreeskbreason+0x48/0xb0 mse102xtxwork+0x164/0x35c [mse102x] processonework+0x138/0x260 workerthread+0x32c/0x438 kthread+0x118/0x11c retfromfork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)
In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix KMSAN warning in decodegetfattrattrs()
Fix the following KMSAN warning:
CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BADPAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrgeneric+0x806/0xb00 nfs4xdrdecgetattr+0x1de/0x240 rpcauthunwraprespdecode+0xab/0x100 rpcauthunwrapresp+0x95/0xc0 calldecode+0x4ff/0xb50 rpcexecute+0x57b/0x19d0 rpcexecute+0x368/0x5e0 rpcruntask+0xcfe/0xee0 nfs4procgetattr+0x5b5/0x990 nfsrevalidateinode+0x477/0xd00 nfsaccessgetcached+0x1021/0x1cc0 nfsdoaccess+0x9f/0xae0 nfspermission+0x1e4/0x8c0 inodepermission+0x356/0x6c0 linkpathwalk+0x958/0x1330 pathlookupat+0xce/0x6b0 filenamelookup+0x23e/0x770 vfsstatx+0xe7/0x970 vfsfstatat+0x1f2/0x2c0 sesysnewfstatat+0x67/0x880 x64sysnewfstatat+0xbd/0x120 x64syscall+0x1826/0x3cf0 dosyscall64+0xd0/0x1b0 entrySYSCALL64afterhwframe+0x77/0x7f
The KMSAN warning is triggered in decodegetfattrattrs(), when calling decodeattrmdsthreshold(). It appears that fattr->mdsthreshold is not initialized.
Fix the issue by initializing fattr->mdsthreshold to NULL in nfsfattrinit().
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Add sendpageok() check to disable MSGSPLICEPAGES
While running ISER over SIW, the initiator machine encounters a warning from skbsplicefromiter() indicating that a slab page is being used in sendpage. To address this, it is better to add a sendpageok() check within the driver itself, and if it returns 0, then MSGSPLICEPAGES flag should be disabled before entering the network stack.
A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/
WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skbsplicefromiter+0x173/0x320 Call Trace: tcpsendmsglocked+0x368/0xe40 siwtxhdt+0x695/0xa40 [siw] siwqpsqprocess+0x102/0xb00 [siw] siwsqresume+0x39/0x110 [siw] siwrunsq+0x74/0x160 [siw] kthread+0xd2/0x100 retfromfork+0x34/0x40 retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free of network namespace.
Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0]
The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying.
The root cause is wrong reference counting for network namespace.
CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.
The repro steps are roughly:
1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS
We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIGNETNSREFCNTTRACKER is enabled.
When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.
Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcpwritetimerhandler().").
Note that we need to move putnet() from cifsputtcpsession() to cleandemultiplexinfo(); otherwise, sockcreate() still could touch a freed netns while cifsd tries to reconnect from cifsdemultiplexthread().
Also, maybegetnet() cannot be put just before sockcreate() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.
[0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: clsbpf schingress nlsutf8 cifs cifsarc4 cifsmd4 dnsresolver tcpdiag inetdiag veth xtstate xtconnmark nfconntracknetlink xtnat xtstatistic xtMASQUERADE xtmark xtaddrtype iptREJECT nfrejectipv4 nftchainnat nfnat xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment nftcompat nftables nfnetlink overlay nlsascii nlscp437 sunrpc vfat fat aesceblk aescecipher ghashce sm4cecipher sm4 sm3ce sm3 sha3ce sha512ce sha512arm64 sha1ce ena button schfqcodel loop fuse configfs dmisysfs sha2ce sha256arm64 dmmirror dmregionhash dmlog dmmod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fibruleslookup+0x44/0x238 lr : fiblookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fibruleslookup+0x44/0x238 fiblookup+0x64/0xbc iprouteoutputkeyhashrcu+0x2c4/0x398 iprouteoutputkeyhash+0x60/0x8c tcpv4connect+0x290/0x488 inetstreamconnect+0x108/0x3d0 inetstreamconnect+0x50/0x78 kernelconnect+0x6c/0xac genericipconne ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: kTLS, Fix incorrect page refcounting
The kTLS tx handling code is using a mix of getpage() and pagerefinc() APIs to increment the page reference. But on the release path (mlx5ektlstxhandleresyncdumpcomp()), only putpage() is used.
This is an issue when using pages from large folios: the getpage() references are stored on the folio page while the pagerefinc() references are stored directly in the given page. On release the folio page will be dereferenced too many times.
This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")).
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSOMAXBUFFSIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it.
For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dmadesc[N + 0], dmadesc[N + 1], dmadesc[N + 2]. Then three elements of txq->txskbuffdma[] will be allocated to hold extra information to be reused in stmmactxclean(): txq->txskbuffdma[N + 0], txq->txskbuffdma[N + 1], txq->txskbuffdma[N + 2]. Now we focus on txq->txskbuffdma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmactxclean() will try to unmap the DMA buffer ONLYIF txq->txskbuffdma[entry].buf is a valid buffer address.
The expected behavior that saves DMA buffer address of this non-paged data to txq->txskbuffdma[entry].buf is: txq->txskbuffdma[N + 0].buf = NULL; txq->txskbuffdma[N + 1].buf = NULL; txq->txskbuffdma[N + 2].buf = dmamapsingle(); Unfortunately, the current code misbehaves like this: txq->txskbuffdma[N + 0].buf = dmamapsingle(); txq->txskbuffdma[N + 1].buf = NULL; txq->txskbuffdma[N + 2].buf = NULL;
On the stmmactxclean() side, when dmadesc[N + 0] is closed by the DMA engine, txq->txskbuffdma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dmadesc[N + 1], dmadesc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :(
In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually.
This patch corrects DMA map/unmap sequences by fixing the array index for txq->txskbuffdma[entry].buf when assigning DMA buffer address.
Tested and verified on DWXGMAC CORE 3.20a
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix invalid port index for parent device
In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), the enumeration over self ID sequence was refactored with some helper functions with KUnit tests. These helper functions are guaranteed to work expectedly by the KUnit tests, however their application includes a mistake to assign invalid value to the index of port connected to parent device.
This bug affects the case that any extra node devices which has three or more ports are connected to 1394 OHCI controller. In the case, the path to update the tree cache could hits WARNON(), and gets general protection fault due to the access to invalid address computed by the invalid value.
This commit fixes the bug to assign correct port index.
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIGBROKEN
Hide KVM's ptmode module param behind CONFIGBROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk.
For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and stays disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTITCTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM:
If the logical processor is operating with Intel PT enabled (if IA32RTITCTL.TraceEn = 1) at the time of VM entry, the "load IA32RTITCTL" VM-entry control must be 0.
On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: Fix packet corruption in vmxnet3xdpxmitframe
Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.
If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.
vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:
page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATODEVICE);
The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void )xdpf, that is, xdp->data - xdp->datahardstart.
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3.
In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages.
Per the APM:
The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0.
And the SDM's much more explicit:
4:0 Ignored
Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Add hashkeylength check
Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.
In the Linux kernel, the following vulnerability has been resolved:
virtiopci: Fix admin vq cleanup by using correct info pointer
vpmodernavqcleanup() and vpdelvqs() clean up admin vq resources by virtiopcivqinfo pointer. The info pointer of admin vq is stored in vpdev->adminvq.info instead of vpdev->vqs[]. Using the info pointer from vpdev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vpmodernavqcleanup() and vpdelvqs(), get the info pointer from vpdev->adminvq.info for admin vq to clean up the resources. Also make info ptr as argument of vpdelvq() to be symmetric with vpsetupvq().
vpreset calls vpmodernavqcleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vpreset+0x57/0x90 [virtiopci] Call Trace: <TASK> ... ? vpreset+0x57/0x90 [virtiopci] ? vpreset+0x38/0x90 [virtiopci] virtioresetdevice+0x1d/0x30 removevqcommon+0x1c/0x1a0 [virtionet] virtnetremove+0xa1/0xc0 [virtionet] virtiodevremove+0x46/0xa0 ... virtiopcidriverexit+0x14/0x810 [virtiopci] ==================================================================
In the Linux kernel, the following vulnerability has been resolved:
sctp: properly validate chunk size in sctpsfootb()
A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot:
BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: assign dhkey to NULL after kfreesensitive
ctrl->dhkey might be used across multiple calls to nvmetsetupdhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmetdestroyauth().
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
xhci: tegra: fix checked USB2 port number
If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller.
Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access.
[ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegraxusbenterelpg+0x23c/0x658 [ 117.222021] tegraxusbruntimesuspend+0x40/0x68 [ 117.227260] pmgenericruntimesuspend+0x30/0x50 [ 117.232847] rpmcallback+0x84/0x3c0 [ 117.237038] rpmsuspend+0x2dc/0x740 [ 117.241229] pmruntimework+0xa0/0xb8 [ 117.245769] processscheduledworks+0x24c/0x478 [ 117.251007] workerthread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] retfromfork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Fix UAF on isosocktimeout
conn->sk maybe have been unlinked/freed while waiting for isoconnlock so this checks if the conn->sk is still valid by checking if it part of isosklist.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix UAF on scosocktimeout
conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix shift-out-of-bounds bug
Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel.
UBSAN: shift-out-of-bounds in arch/arm64/kvm/sysregs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dumpbacktrace+0xa0/0x128 showstack+0x20/0x38 dumpstacklvl+0x74/0x90 dumpstack+0x18/0x28 ubsanhandleshiftoutofbounds+0xf8/0x1e0 resetclidr+0x10c/0x1c8 kvmresetsysregs+0x50/0x1c8 kvmresetvcpu+0xec/0x2b0 kvmvcpusettarget+0x84/0x158 kvmvcpusettarget+0x138/0x168 kvmarchvcpuioctlvcpuinit+0x40/0x2b0 kvmarchvcpuioctl+0x28c/0x4b8 kvmvcpuioctl+0x4bc/0x7a8 arm64sysioctl+0xb4/0x100 invokesyscall+0x70/0x100 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x3c/0x158 el0t64synchandler+0x120/0x130 el0t64sync+0x194/0x198
In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix movenormalpmd/retractpagetables race
In mremap(), movepagetables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved.
At that point, the mmaplock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, movepgtentry(NORMALPMD, ...) is called, which first takes rmap locks, then does movenormalpmd(). movenormalpmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination.
The problem is: The rmap locks, which protect against concurrent page table removal by retractpagetables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap:
process A process B ========= ========= mremap mremapto movevma movepagetables getoldpmd allocnewpmd PREEMPT madvise(MADVCOLLAPSE) domadvise madvisewalkvmas madvisevmabehavior madvisecollapse hpagecollapsescanfile collapsefile retractpagetables immaplockread(mapping) pmdpcollapseflush immapunlockread(mapping) movepgtentry(NORMALPMD, ...) takermaplocks movenormalpmd droprmaplocks
When this happens, movenormalpmd() can end up creating bogus PMD entries in the line pmdpopulate(mm, newpmd, pmdpgtable(pmd)). The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation.
Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmdnone() check.
Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIGREADONLYTHPFORFS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that.
Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.
In the Linux kernel, the following vulnerability has been resolved:
uprobe: avoid out-of-bounds memory access of fetching args
Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.
Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And storetraceargs() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.
It could be reproduced by following steps: 1. build kernel with CONFIGKASAN enabled 2. save follow program as test.c
\#include <stdio.h> \#include <stdlib.h> \#include <string.h>
// If string length large than MAXSTRINGSIZE, the fetchstorestrlen() // will return 0, cause getdatasize() return shorter size, and // storetraceargs() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093
void generatestring(char str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; }
void printstring(char str) { printf("%s\n", str); }
int main() { char tmp[STRLEN];
generatestring(tmp, STRLEN); printstring(tmp);
return 0; } 3. compile program gcc -o test test.c
4. get the offset of printstring() objdump -t test | grep -w printstring 0000000000401199 g F .text 000000000000001b printstring
5. configure uprobe with offset 0x1199 off=0x1199
cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobeevents echo 1 > events/uprobes/enable echo 1 > tracingon
6. run test, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpyfromuser+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x27/0x310 kasanreport+0x10f/0x120 ? strncpyfromuser+0x1d6/0x1f0 strncpyfromuser+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 processfetchinsn+0xb26/0x1470 ? pfxprocessfetchinsn+0x10/0x10 ? rawspinlock+0x85/0xe0 ? pfxrawspinlock+0x10/0x10 ? pteoffsetmap+0x1f/0x2d0 ? unwindnextframe+0xc5f/0x1f80 ? archstackwalk+0x68/0xf0 ? isbpftextaddress+0x23/0x30 ? kerneltextaddress.part.0+0xbb/0xd0 ? kerneltextaddress+0x66/0xb0 ? unwindgetreturnaddress+0x5e/0xa0 ? pfxstacktraceconsumeentry+0x10/0x10 ? archstackwalk+0xa2/0xf0 ? rawspinlockirqsave+0x8b/0xf0 ? pfxrawspinlockirqsave+0x10/0x10 ? depotallocstack+0x4c/0x1f0 ? rawspinunlockirqrestore+0xe/0x30 ? stackdepotsaveflags+0x35d/0x4f0 ? kasansavestack+0x34/0x50 ? kasansavestack+0x24/0x50 ? mutexlock+0x91/0xe0 ? pfxmutexlock+0x10/0x10 prepareuprobebuffer.part.0+0x2cd/0x500 uprobedispatcher+0x2c3/0x6a0 ? pfxuprobedispatcher+0x10/0x10 ? kasanslaballoc+0x4d/0x90 handlerchain+0xdd/0x3e0 handleswbp+0x26e/0x3d0 ? pfxhandleswbp+0x10/0x10 ? uprobepresstepnotifier+0x151/0x1b0 irqentryexittousermode+0xe2/0x1b0 asmexcint3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK>
This commit enforces the buffer's maxlen less than a page-size to avoid storetraceargs() out-of-memory access.
In the Linux kernel, the following vulnerability has been resolved:
parport: Proper fix for array out-of-bounds access
The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.
Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.