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:
<pre>
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, ...));
}
</pre>
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().
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:
-
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.
-
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.
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]
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The UAF is driven by a race between tcp_connect() freeing MD5 keys and softirq RX handlers (tcp_v4_rcv→tcp_inbound_hash→__tcp_md5_do_lookup) on an ehashed SYN_SENT socket; forged inbound TCP segments reach this path over the network, matching internet-facing BGP/TCP-AO peers.
AC:L - The attacker controls both sides of the race by calling connect() while concurrently spraying TCP segments (raw sockets or as the remote peer) at the socket 4-tuple; no victim-dependent timing or memory layout is required beyond standard heap reuse inherent to slab UAF.
PR:N - Exploitation needs no host root: a remote BGP/TCP peer can send segments during the victim's outbound connect, and the demonstrated userns repro uses only uid=1000 with CLONE_NEWUSER|CLONE_NEWNET caps to install TCP_MD5/TCP-AO keys and trigger the race.
UI:N - No end-user action is required; the bug fires during automated connect() handling (e.g., BGP session establishment) concurrent with inbound packet processing, without anyone opening files or confirming prompts.
S:U - Impact is confined to kernel memory integrity/availability on the affected host; it does not cross VM, container, or IOMMU security boundaries into another authority.
C:H - Concurrent hlist_for_each_entry_rcu() over tcp_md5sig_key objects that are being kfree()'d is a slab use-after-free; freed key memory can be reallocated and read during RCU traversal, enabling kernel information disclosure.
I:H - The per-key UAF corrupts RCU list traversal in softirq and allows attacker-influenced slab reuse, providing a standard path to heap grooming and arbitrary kernel write or control-flow hijack.
A:H - The symmetric TCP-AO connect race in the same window produces kernel GPF/oops in softirq (KASAN wild-memory-access); this MD5-key UAF in the identical SYN_SENT/ehash race window can panic or hang the system.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The UAF is driven by a race between tcp_connect() freeing MD5 keys and softirq RX handlers (tcp_v4_rcv→tcp_inbound_hash→__tcp_md5_do_lookup) on an ehashed SYN_SENT socket; forged inbound TCP segments reach this path over the network, matching internet-facing BGP/TCP-AO peers.
AC:L - The attacker controls both sides of the race by calling connect() while concurrently spraying TCP segments (raw sockets or as the remote peer) at the socket 4-tuple; no victim-dependent timing or memory layout is required beyond standard heap reuse inherent to slab UAF.
PR:N - Exploitation needs no host root: a remote BGP/TCP peer can send segments during the victim's outbound connect, and the demonstrated userns repro uses only uid=1000 with CLONE_NEWUSER|CLONE_NEWNET caps to install TCP_MD5/TCP-AO keys and trigger the race.
UI:N - No end-user action is required; the bug fires during automated connect() handling (e.g., BGP session establishment) concurrent with inbound packet processing, without anyone opening files or confirming prompts.
S:U - Impact is confined to kernel memory integrity/availability on the affected host; it does not cross VM, container, or IOMMU security boundaries into another authority.
C:H - Concurrent hlist_for_each_entry_rcu() over tcp_md5sig_key objects that are being kfree()'d is a slab use-after-free; freed key memory can be reallocated and read during RCU traversal, enabling kernel information disclosure.
I:H - The per-key UAF corrupts RCU list traversal in softirq and allows attacker-influenced slab reuse, providing a standard path to heap grooming and arbitrary kernel write or control-flow hijack.
A:H - The symmetric TCP-AO connect race in the same window produces kernel GPF/oops in softirq (KASAN wild-memory-access); this MD5-key UAF in the identical SYN_SENT/ehash race window can panic or hang the system.
CVSS 3.1