UBUNTU-CVE-2026-72139: Use After Free
In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5siginfo kfree past RCU grace period in tcpconnect The md5+ao reconciliation in tcpconnect() (net/ipv4/tcpoutput.c) has two symmetric branches: if (needsmd5) { tcpaodestroysock(sk, false); } else if (needsao) { tcpclearmd5list(sk); kfree(rcureplacepointer(tp->md5siginfo, NULL, ...)); } Both branches free a per-socket auth-info object while the socket is in TCPSYNSENT and is already on the inet ehash (inserted by inethashconnect() in tcpv4connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bhlocksocknested() is taken. The needsmd5 branch is fixed in the prior patch by re-introducing the callrcu() free in tcpaodestroysock(): the equivalent per-key loop runs inside tcpaoinfofreercu(), the RCU callback, so by the time it frees each tcpaokey all softirq readers that captured the container have already completed rcureadunlock(). The needsao branch is not symmetric in the same way. The container free can be deferred via kfreercu(md5sig, rcu) -- struct tcpmd5siginfo already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcpmd5siginfoadd() rollback paths (net/ipv4/tcpipv4.c:1410, 1436). But the per-key teardown is done by tcpclearmd5list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcpmd5sigkey with bare hlistdel + kfree. A concurrent softirq reader in tcpmd5dolookup() / tcpmd5dolookupexact() (tcpipv4.c:1253, 1298) walks the same list via hlistforeachentryrcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcpconnect() to kfreercu() so the md5siginfo container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfreercu() is a macro that expects an lvalue. 2. Make tcpclearmd5list() RCU-safe by replacing hlistdel + kfree(key) with hlistdelrcu + kfreercu(key, rcu). struct tcpmd5sigkey already carries the rcu member (include/net/tcp.h:1995) and tcpmd5dodel() (net/ipv4/tcpipv4.c:1456) already uses kfreercu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcpclearmd5list() is tcpmd5destructsock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needsao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needsmd5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34~24.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1012.12~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-34.34 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1007.8 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1012.12 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1020.20 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The affected software list includes ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-hwe-edge, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, and ubuntu/linux-aws-5.0. The supplied data does not identify specific fixed or affected package versions.
What runtime conditions are involved in reaching the vulnerable code path?
The issue occurs during tcp_connect() while a socket is in TCP_SYN_SENT and has already been inserted into the inet ehash. It involves reconciliation between TCP MD5 signature and TCP Authentication Option information while softirq receive-path readers may hold an RCU-obtained pointer to the authentication data.
Why is this a use-after-free condition?
The affected branch clears the MD5 signature information and frees its container while RCU readers may still be using it. The described resolution defers the free until after an RCU grace period using kfree_rcu().