In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix possible badness in FREESTATEID
When multiple FREESTATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors.
In nfsd4freestateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4putstid(), that allows another FREESTATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.
In the Linux kernel, the following vulnerability has been resolved:
slip: make slhcremember() more robust against malicious packets
syzbot found that slhcremember() was missing checks against malicious packets [1].
slhcremember() only checked the size of the packet was at least 20, which is not good enough.
We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.
Add iph and th pointers to make the code more readable.
[1]
BUG: KMSAN: uninit-value in slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 pppreceivenonmpframe+0xe45/0x35e0 drivers/net/ppp/pppgeneric.c:2455 pppreceiveframe drivers/net/ppp/pppgeneric.c:2372 [inline] pppdorecv+0x65f/0x40d0 drivers/net/ppp/pppgeneric.c:2212 pppinput+0x7dc/0xe60 drivers/net/ppp/pppgeneric.c:2327 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 syssendmmsg+0x3c1/0x960 net/socket.c:2742 dosyssendmmsg net/socket.c:2771 [inline] sesyssendmmsg net/socket.c:2768 [inline] x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Uninit was created at: slabpostallochook mm/slub.c:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 syssendmmsg+0x3c1/0x960 net/socket.c:2742 dosyssendmmsg net/socket.c:2771 [inline] sesyssendmmsg net/socket.c:2768 [inline] x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Prevent NULL-pointer dereference in nfs42completecopies()
On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42completecopies() got a NULL-pointer dereference crash with the following syslog:
[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs ocfs2dlmfs ocfs2stacko2cb ocfs2dlm vhostnet vhost vhostiotlb tap tun iptrpfilter xtmultiport ipsethaship ipsethashnet xfrminterface xfrm6tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519generic veth xtaddrtype xtset nfconntracknetlink ipsethashipportnet ipsethashipportip ipsetbitmapport ipsethashipport dummy ipset ipvssh ipvswrr ipvsrr ipvs iptablefilter schingress nfnetlinkcttimeout vportgre ipgre iptunnel gre vportgeneve geneve vportvxlan vxlan ip6udptunnel udptunnel openvswitch nfconncount dmroundrobin dmservicetime dmmultipath xtnat xtMASQUERADE nftchainnat nfnat xtmark xtconntrack xtcomment nftcompat nftcounter nftables nfnetlink ocfs2 ocfs2nodemanager ocfs2stackglue iscsitcp libiscsitcp libiscsi scsitransportiscsi ipmissif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cascache casdisk ses enclosure scsitransportsas sg acpiipmi ipmisi ipmidevintf ipmimsghandler iptables vfiopci vfiopcicore vfiovirqfd vfioiommutype1 vfio dmmirror dmregionhash dmlog dmmod nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc fuse xfs libcrc32c ast drmvramhelper qla2xxx drmkmshelper syscopyarea crct10difce sysfillrect ghashce sysimgblt sha2ce fbsysfops cec sha256arm64 sha1ce drmttmhelper ttm nvmefc igb sbsagwdt nvmefabrics drm nvmecore i2calgobit i40e scsitransportfc megaraidsas aesneonbs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBEV3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4reclaimopenstate+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4reclaimopenstate+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---
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:
Bluetooth: hciconn: Fix UAF in hcienhancedsetupsync
This checks if the ACL connection remains valid as it could be destroyed while hcienhancedsetupsync is pending on cmdsync leading to the following trace:
BUG: KASAN: slab-use-after-free in hcienhancedsetupsync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37
CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? hcienhancedsetupsync+0x91b/0xa60 printreport+0x152/0x4c0 ? hcienhancedsetupsync+0x91b/0xa60 ? virtaddrvalid+0x1fa/0x420 ? hcienhancedsetupsync+0x91b/0xa60 kasanreport+0xda/0x1b0 ? hcienhancedsetupsync+0x91b/0xa60 hcienhancedsetupsync+0x91b/0xa60 ? pfxhcienhancedsetupsync+0x10/0x10 ? pfxmutexlock+0x10/0x10 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 ? pfxlockacquire+0x10/0x10 ? pfxprocessonework+0x10/0x10 ? assignwork+0x167/0x240 workerthread+0x5b7/0xf60 ? kthreadparkme+0xac/0x1c0 ? pfxworkerthread+0x10/0x10 ? pfxworkerthread+0x10/0x10 kthread+0x293/0x360 ? pfxkthread+0x10/0x10 retfromfork+0x2f/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 34: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 hciconnadd+0x187/0x17d0 hciconnectsco+0x2e1/0xb90 scosockconnect+0x2a2/0xb80 sysconnect+0x227/0x2a0 x64sysconnect+0x6d/0xb0 dosyscall64+0x71/0x140 entrySYSCALL64afterhwframe+0x76/0x7e
Freed by task 37: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x101/0x160 kfree+0xd0/0x250 devicerelease+0x9a/0x210 kobjectput+0x151/0x280 hciconndel+0x448/0xbf0 hciabortconnsync+0x46f/0x980 hcicmdsyncwork+0x1c2/0x330 processonework+0x7d9/0x1360 workerthread+0x5b7/0xf60 kthread+0x293/0x360 retfromfork+0x2f/0x70 retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix macvlan leak by synchronizing access to macfilterhash
This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->macfilterhash. The leak occurs when multiple threads attempt to modify the macfilterhash simultaneously, leading to inconsistent state and potential memory leaks.
To fix this, we now wrap the calls to i40edelmacfilter() and zeroing vf->defaultlanaddr.addr with spinlock/unlockbh(&vsi->macfilterhashlock), ensuring atomic operations and preventing concurrent access.
Additionally, we add lockdepassertheld(&vsi->macfilterhashlock) in i40eaddmacfilter() to help catch similar issues in the future.
Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the macfilterhash.
This synchronization ensures the integrity of the macfilterhash and prevents the described leak.
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:
mptcp: handle consistently DSS corruption
Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUGNET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.
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)