In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.
OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.
ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.
ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.
Initializing the whole thing before parsing is needed because ND packet may not contain all the options.
The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: dwmac-tegra: Read iommu stream id from device tree
Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBEWRAPAXIASID0CTRL register.
The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.
Example dmesg errors when an ethernet cable is connected to MGBE1:
[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEMTYPEPAGEPOOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcupreempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handlesoftirqs+0x98/0x368 [ 181.922978] lr : dosoftirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handlesoftirqs+0x98/0x368 (P) [ 181.974240] dosoftirq+0x18/0x20 [ 181.977743] dosoftirq+0x14/0x28 [ 181.981415] callonirqstack+0x24/0x30 [ 181.985180] dosoftirqownstack+0x20/0x30 [ 181.989379] irqexitrcu+0x114/0x140 [ 181.993142] irqexitrcu+0x14/0x28 [ 181.996816] el1interrupt+0x44/0xb8 [ 182.000316] el1h64irqhandler+0x14/0x20 [ 182.004343] el1h64irq+0x80/0x88 [ 182.007755] cpuidleenterstate+0xc4/0x4a8 (P) [ 182.012305] cpuidleenter+0x3c/0x58 [ 182.015980] cpuidleidlecall+0x128/0x1c0 [ 182.020005] doidle+0xe0/0xf0 [ 182.023155] cpustartupentry+0x3c/0x48 [ 182.026917] secondarystartkernel+0xdc/0x120 [ 182.031379] secondaryswitched+0x74/0x78 [ 212.971162] rcu: INFO: rcupreempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcunode structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---
Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe, resulting in arbitrary read/write in kernel memory, lateral privilege escalation, and container escape.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbdsessionlookup | smb2sesssetup sess = xaload | | | xaerase(&conn->sessions, sess->id); | | ksmbdsessiondestroy(sess) --> kfree(sess) | // UAF! | sess->lastactive = jiffies | +
This patch add rwsem to fix race condition between ksmbdsessionlookup and ksmbdexpiresession.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Do not call scsidone() from srpabort()
After scmdehaborthandler() has called the SCSI LLD ehaborthandler callback, it performs one of the following actions: Call scsiqueueinsert(). Call scsifinishcommand(). Call scsiehscmdadd(). Hence, SCSI abort handlers must not call scsidone(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsidone() call from srpabort(). Keep the srpfreereq() call before returning SUCCESS because we may not see the command again if SUCCESS is returned.
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: pscsi: Fix bioput() for error case
As of commit 066ff571011d ("block: turn biokmalloc into a simple kmalloc wrapper"), a bio allocated by biokmalloc() must be freed by biouninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in biofree().
In the Linux kernel, the following vulnerability has been resolved:
crypto: safexcel - Add error handling for dmamapsg() calls
Macro dmamapsg() may return 0 on error. This patch enables checks in case of the macro failure and ensures unmapping of previously mapped buffers with dmaunmapsg().
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2isvalidoplockbreak()
Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2isvalidleasebreak()
Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2reconnectserver()
The Linux kernel CVE team has assigned CVE-2024-35870 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051940-CVE-2024-35870-3c02@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in isvalidoplockbreak()
Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifssignalcifsdforreconnect()
Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in ofmodalias()
In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix invalid unregister error path
The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.
This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayedwork() and cephmoncstop()
The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if curmon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->curmon and monc->hunting as part of closing the session in cephmoncstop() - bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting) - call canceldelayedworksync() after the session is closed
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-clt: Reset cid to connum - 1 to stay in bounds
In the function initconns(), after the createcon() and createcm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to cltpath->s.connum.
This commits resets the cid to cltpath->s.connum - 1, to stay in bounds in the cleanup loop later.
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix race between timeout and normal completion
If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.
Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.
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:
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: 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:
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe.
refcountt: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcountwarnsaturate+0x9c/0x140 Workqueue: events smclgrterminatework [smc] Call trace: refcountwarnsaturate+0x9c/0x140 smclgrterminate.part.45+0x2a8/0x370 [smc] smclgrterminatework+0x28/0x30 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118
or
refcountt: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcountwarnsaturate+0xf0/0x140 Workqueue: smchswq smclistenwork [smc] Call trace: refcountwarnsaturate+0xf0/0x140 smcrlinkput+0x1cc/0x1d8 [smc] smcconnfree+0x110/0x1b0 [smc] smcconnabort+0x50/0x60 [smc] smclistenfinddevice+0x75c/0x790 [smc] smclistenwork+0x368/0x8a0 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118
It is caused by repeated release of LGR/link refcnt. One suspect is that smcconnfree() is called repeatedly because some smcconnfree() from server listening path are not protected by sock lock.
e.g.
Calls under socklock | smclistenwork ------------------------------------------------------- locksock(sk) | smcconnabort smcconnfree | \- smcconnfree \- smcrlinkput | \- smcrlinkput (duplicated) releasesock(sk)
So here add sock lock protection in smclistenwork() path, making it exclusive with other connection operations.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: protect link down work from execute after lgr freed
link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled.
The relevant crash call stack as follows: listdel corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smclinkdownwork [smc] RIP: 0010:listdelentryvalid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsemdownwriteslowpath+0x17e/0x470 smclinkdownwork+0x3c/0x60 [smc] processonework+0x1ac/0x350 workerthread+0x49/0x2f0 ? rescuerthread+0x360/0x360 kthread+0x118/0x140 ? kthreadbindmask+0x60/0x60 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"
The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.
Compared with other rdma drivers, a bigger timeout is used.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix racy issue from session lookup and expire
Increment the session reference count within the lock for lookup to avoid racy issue with session expire.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()
After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't replace page in rqpages if it's a continuation of last page
The splice read calls nfsdspliceactor to put the pages containing file data into the svcrqst->rqpages array. It's possible however to get a splice result that only has a partial page at the end, if (e.g.) the filesystem hands back a short read that doesn't cover the whole page.
nfsdspliceactor will plop the partial page into its rqpages array and return. Then later, when nfsdspliceactor is called again, the remainder of the page may end up being filled out. At this point, nfsdspliceactor will put the page into the array again corrupting the reply. If this is done enough times, rqnextpage will overrun the array and corrupt the trailing fields -- the rqrespages and rqnextpage pointers themselves.
If we've already added the page to the array in the last pass, don't add it to the array a second time when dealing with a splice continuation. This was originally handled properly in nfsdspliceactor, but commit 91e23b1c3982 ("NFSD: Clean up nfsdspliceactor()") removed the check for it.
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: Fix napi rx poll issue
When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic.
BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:devgroreceive+0x3a/0x620 [...] Call Trace: <IRQ> ? diebody+0x68/0xb0 ? pagefaultoops+0x379/0x3e0 ? excpagefault+0x4f/0xa0 ? asmexcpagefault+0x22/0x30 ? pfxt7xxccmnirecvskb+0x10/0x10 [mtkt7xx (HASH:1400 7)] ? devgroreceive+0x3a/0x620 napigroreceive+0xad/0x170 t7xxccmnirecvskb+0x48/0x70 [mtkt7xx (HASH:1400 7)] t7xxdpmaifnapirxpoll+0x590/0x800 [mtkt7xx (HASH:1400 7)] netrxaction+0x103/0x470 irqexitrcu+0x13a/0x310 sysvecapictimerinterrupt+0x56/0x90 </IRQ>
bnxten: Set DMA unmap len correctly for XDPREDIRECT