CVE-2026-72139
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer md5sig_info kfree past RCU grace period in tcp_connect
The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches:
Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken.
The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock().
Leer descripción completaMostrar menos
The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() 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:
The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (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 needs_ao 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 needs_md5 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]
Detalles técnicos trazas, registros y código del informe original
if (needs_md5) {
tcp_ao_destroy_sock(sk, false);
} else if (needs_ao) {
tcp_clear_md5_list(sk);
kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...));
}
1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the
md5sig_info container joins the rest of the md5sig lifecycle.
The local-variable lift is mechanical and required because
kfree_rcu() is a macro that expects an lvalue.
2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del +
kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct
tcp_md5sig_key already carries the rcu member
(include/net/tcp.h:1995) and tcp_md5_do_del()
(net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this
restores the lifecycle invariant the rest of the file follows
rather than introducing a one-off.CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Puntuación base: 9.8
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.63%
- Percentil entre todas las CVEs puntuadas: 48
- Fecha de la puntuación: 5/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1190Exploit Public-Facing Applicationinitial access60 %
Inferido por reglas deterministas a partir del vector CVSS y la CWE. Solo orientativo.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-72139",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 9.8,
"attackVector": "NETWORK",
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "NONE",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.9,
"exploitabilityScore": 3.9
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
"lessThan": "33a1bee413628378fd036a4f2b17ba86b0bc560c",
"versionType": "git"
},
{
"status": "affected",
"version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
"lessThan": "da48b9bf1eb95a9cfd09d615ca58cfc2b03de369",
"versionType": "git"
},
{
"status": "affected",
"version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
"lessThan": "b74cd55038905d5e74c1de109ab78a30b2ea0e1f",
"versionType": "git"
}
],
"programFiles": [
"net/ipv4/tcp_ipv4.c",
"net/ipv4/tcp_output.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "6.18"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "6.18",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.18.40",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.1.5",
"versionType": "semver",
"lessThanOrEqual": "7.1.*"
},
{
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"net/ipv4/tcp_ipv4.c",
"net/ipv4/tcp_output.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-08-15T06:21:31.460",
"references": [
{
"url": "https://git.kernel.org/stable/c/33a1bee413628378fd036a4f2b17ba86b0bc560c",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/b74cd55038905d5e74c1de109ab78a30b2ea0e1f",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/da48b9bf1eb95a9cfd09d615ca58cfc2b03de369",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: defer md5sig_info kfree past RCU grace period in tcp_connect\n\nThe md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c)\nhas two symmetric branches:\n\n\tif (needs_md5) {\n\t\ttcp_ao_destroy_sock(sk, false);\n\t} else if (needs_ao) {\n\t\ttcp_clear_md5_list(sk);\n\t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...));\n\t}\n\nBoth branches free a per-socket auth-info object while the socket is\nin TCP_SYN_SENT and is already on the inet ehash (inserted by\ninet_hash_connect() in tcp_v4_connect()). Both branches are reachable\nby softirq RX-path readers that load the corresponding info pointer\nvia implicit RCU before bh_lock_sock_nested() is taken.\n\nThe needs_md5 branch is fixed in the prior patch by re-introducing\nthe call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key\nloop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the\ntime it frees each tcp_ao_key all softirq readers that captured the\ncontainer have already completed rcu_read_unlock().\n\nThe needs_ao branch is not symmetric in the same way. The container\nfree can be deferred via kfree_rcu(md5sig, rcu) -- struct\ntcp_md5sig_info already has the required rcu member\n(include/net/tcp.h:1999-2002), and the rest of the tree already does\nthis in the tcp_md5sig_info_add() rollback paths\n(net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done\nby tcp_clear_md5_list() in process context BEFORE the container's\nRCU grace period: it walks &md5sig->head and frees each\ntcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq\nreader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact()\n(tcp_ipv4.c:1253, 1298) walks the same list via\nhlist_for_each_entry_rcu() and races with that bare kfree on the\nkeys themselves -- a per-key slab use-after-free of the same class\nas the TCP-AO bug, on the same race window.\n\nFix this in two halves:\n\n 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the\n md5sig_info container joins the rest of the md5sig lifecycle.\n The local-variable lift is mechanical and required because\n kfree_rcu() is a macro that expects an lvalue.\n\n 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del +\n kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct\n tcp_md5sig_key already carries the rcu member\n (include/net/tcp.h:1995) and tcp_md5_do_del()\n (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this\n restores the lifecycle invariant the rest of the file follows\n rather than introducing a one-off.\n\nThe other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock()\n(net/ipv4/tcp.c:412), which runs from the sock destructor when the\nsocket is already unhashed and unreachable; the extra grace period\nthere is unnecessary but harmless. Making the helper unconditionally\nRCU-safe is the cleaner contract.\n\nThe needs_ao branch is not reachable by the userns reproducer used\nto demonstrate the AO-side splat (the repro installs both keys but\nends up in the needs_md5 branch because the connect peer matches\nthe MD5 key, not the AO key); however the symmetric race exists\nand a maintainer touching this code should not have to think about\nwhich branch escapes RCU and which one does not.\n\n[also credits to Qihang, who found that this races with tcp-diag]"
}
],
"lastModified": "2026-08-17T06:18:13.823",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}