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---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.
9p: avoid putting oldfid in p9clientwalk() error path
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:
mptcp: fix double-free on socket dismantle
The Linux kernel CVE team has assigned CVE-2024-26782 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26782-71ca@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
igc: avoid returning frame twice in XDPREDIRECT
The Linux kernel CVE team has assigned CVE-2024-26853 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041723-CVE-2024-26853-b549@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling cryptofinalizerequest, BH should be disabled to avoid triggering the following calltrace:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/cryptoengine.c:58 cryptofinalizerequest+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cryptofinalizerequest+0xa0/0x118 lr : cryptofinalizerequest+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: cryptofinalizerequest+0xa0/0x118 cryptofinalizeaeadrequest+0x18/0x30 zynqmphandleaesreq+0xcc/0x388 cryptopumpwork+0x168/0x2d8 kthreadworkerfn+0xfc/0x3a0 kthread+0x118/0x138 retfromfork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [<ffffffc0812416f8>] rawspinunlockirqrestore+0x70/0xb0 hardirqs last disabled at (40): [<ffffffc08122d208>] el1dbg+0x28/0x90 softirqs last enabled at (36): [<ffffffc080017dec>] kernelneonbegin+0x8c/0xf0 softirqs last disabled at (34): [<ffffffc080017dc0>] kernelneonbegin+0x60/0xf0 ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
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:
In the Linux kernel, the following vulnerability has been resolved:
udp: do not accept non-tunnel GSO skbs landing in a tunnel
The Linux kernel CVE team has assigned CVE-2024-35884 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051946-CVE-2024-35884-d4a4@gregkh/T
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:
ksmbd: fix slab out of bounds write in smbinheritdacl()
slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.
Dear Linux Developers,
We're reaching out to you as part of the disclosure process of our research.
In our research, which we will present at IEEE Security & Privacy in May 2024, we found that attackers can not only create TCP-spoofed connections (which was already known), but can also reliably transmit IP-spoofed data over such connections. This has security implications for applications that rely on TCP endpoint IP addresses, such as firewalling or host-based authentication (e.g., SMTP/SPF, of DBs).
We basically discovered two TCP spoofing primitives. First, attackers can bruteforce the server-chosen send window by acknowledging data that was never sent (what we call "ghost ACKs"; see Figure 3 in the paper). Second, we show that there are side channels that allow the attacker to leak the otherwise-secret server-chosen initial sequence number (ISN). One of these side channels leverages TCP SYN cookies.
We believe that the TCP/IP stack can take countermeasures to prevent such attacks, or at least make them harder. For example, we think that TCP endpoints should ignore ghost ACKs, and have some ideas to randomize the TCP backlog queue to prevent the SYN cookie side channel.
At the same time, we have disclosed our findings to the IETF folks and hope that they have helpful feedback for us.
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipcbufappend() error path:
BUG: KASAN: slab-use-after-free in kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> dumpstack linux/lib/dumpstack.c:88 dumpstacklvl+0xd9/0x1b0 linux/lib/dumpstack.c:106 printaddressdescription linux/mm/kasan/report.c:377 printreport+0xc4/0x620 linux/mm/kasan/report.c:488 kasanreport+0xda/0x110 linux/mm/kasan/report.c:601 kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skbreleasedata+0x5af/0x880 linux/net/core/skbuff.c:1026 skbreleaseall linux/net/core/skbuff.c:1094 kfreeskb linux/net/core/skbuff.c:1108 kfreeskbreason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfreeskb linux/./include/linux/skbuff.h:1244 tipcbufappend+0x425/0xb50 linux/net/tipc/msg.c:186 tipclinkinput+0x224/0x7c0 linux/net/tipc/link.c:1324 tipclinkrcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipcrcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipcudprecv+0x73b/0x8f0 linux/net/tipc/udpmedia.c:390 udpqueuercvoneskb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udpqueuercvskb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udpunicastrcvskb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 udp4librcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ipprotocoldeliverrcu+0x30c/0x4e0 linux/net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2e4/0x520 linux/net/ipv4/ipinput.c:233 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iplocaldeliver+0x18e/0x1f0 linux/net/ipv4/ipinput.c:254 dstinput linux/./include/net/dst.h:461 iprcvfinish linux/net/ipv4/ipinput.c:449 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iprcv+0x2c5/0x5d0 linux/net/ipv4/ipinput.c:569 netifreceiveskbonecore+0x199/0x1e0 linux/net/core/dev.c:5534 netifreceiveskb+0x1f/0x1c0 linux/net/core/dev.c:5648 processbacklog+0x101/0x6b0 linux/net/core/dev.c:5976 napipoll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napipoll linux/net/core/dev.c:6645 netrxaction+0x95a/0xe90 linux/net/core/dev.c:6781 dosoftirq+0x21f/0x8e7 linux/kernel/softirq.c:553 dosoftirq linux/kernel/softirq.c:454 dosoftirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> localbhenableip+0x100/0x120 linux/kernel/softirq.c:381 localbhenable linux/./include/linux/bottomhalf.h:33 rcureadunlockbh linux/./include/linux/rcupdate.h:851 devqueuexmit+0x871/0x3ee0 linux/net/core/dev.c:4378 devqueuexmit linux/./include/linux/netdevice.h:3169 neighhhoutput linux/./include/net/neighbour.h:526 neighoutput linux/./include/net/neighbour.h:540 ipfinishoutput2+0x169f/0x2550 linux/net/ipv4/ipoutput.c:235 ipfinishoutput linux/net/ipv4/ipoutput.c:313 ipfinishoutput+0x49e/0x950 linux/net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 linux/net/ipv4/ipoutput.c:323 NFHOOKCOND linux/./include/linux/netfilter.h:303 ipoutput+0x13b/0x2a0 linux/net/ipv4/ipoutput.c:433 dstoutput linux/./include/net/dst.h:451 iplocalout linux/net/ipv4/ipoutput.c:129 ipsendskb+0x3e5/0x560 linux/net/ipv4/ipoutput.c:1492 udpsendskb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udpsendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inetsendmsg+0x105/0x140 linux/net/ipv4/afinet.c:850 socksendmsgnosec linux/net/socket.c:730 socksendmsg linux/net/socket.c:745 syssendto+0x42c/0x4e0 linux/net/socket.c:2191 dosyssendto linux/net/socket.c:2203 sesyssendto linux/net/socket.c:2199 x64syssendto+0xe0/0x1c0 linux/net/socket.c:2199 dosyscallx64 linux/arch/x86/entry/common.c:52 dosyscall ---truncated---
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:
RDMA/rxe: Fix seg fault in rxecompqueuepkt
In rxecompqueuepkt() an incoming response packet skb is enqueued to the resppkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.
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:
fs/ntfs3: Use variable length array instead of fixed size
Should fix smatch warning: ntfssetlabel() error: builtinmemcpy() 'uni->name' too small (20 vs 256)
In the Linux kernel, the following vulnerability has been resolved:
gve: Clear napi->skb before devkfreeskbany()
gverxfreeskb incorrectly leaves napi->skb referencing an skb after it is freed with devkfreeskbany(). This can result in a subsequent call to napigetfrags returning a dangling pointer.
Fix this by clearing napi->skb before the skb is freed.
In the Linux kernel, the following vulnerability has been resolved:
tipc: force a dst refcount before doing decryption
As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"):
"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."
On TIPC decryption path it has the same problem, and skbdstforce() should be called before doing decryption to avoid a possible crash.
Shuang reported this issue when this warning is triggered:
[] WARNING: include/net/dst.h:337 tipcskrcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x8664+debug [] Workqueue: crypto cryptdqueueworker [] RIP: 0010:tipcskrcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipcskmcastrcv+0x548/0xea0 [tipc] [] tipcrcv+0xcf5/0x1060 [tipc] [] tipcaeaddecryptdone+0x215/0x2e0 [tipc] [] cryptdaeadcrypt+0xdb/0x190 [] cryptdqueueworker+0xed/0x190 [] processonework+0x93d/0x17e0
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix UAF when resolving a clash
KASAN reports the following UAF:
BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469
Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491 irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommoninterrupt+0x27/0x40
Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491
Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 kasanslabfree+0x180/0x1f0 kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 netifreceiveskbcore.constprop.0+0xb25/0x1510 netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 dosoftirq+0x14f/0x491
The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocessconn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.