Description
In the Linux kernel, the following vulnerability has been resolved:

tcp: restore RCU grace period in tcp_ao_destroy_sock

Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU")
removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that
"the destruction of info/keys is delayed until the socket destructor"
and therefore "no one can discover it anymore".

That argument does not hold for the call site in tcp_connect()
(net/ipv4/tcp_output.c:4327-4332). At that point the socket is in
TCP_SYN_SENT, has already been inserted into the inet ehash by
inet_hash_connect() in tcp_v4_connect(), and is therefore very much
discoverable: any softirq running tcp_v4_rcv() on another CPU can take
the socket out of the ehash, walk into tcp_inbound_hash(), and load
tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on
the destroying CPU.

The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208)
which re-loads tp->ao_info via rcu_dereference_check(); the re-load can
still observe the (about-to-be-freed) pointer because there is no
synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and
tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is
then walked at line 223:

hlist_for_each_entry_rcu(key, &ao->head, node, ...)

The writer's synchronous kfree() is free to complete between the line
218 re-fetch and the line 223 hlist iteration. The slab is reused
(or simply LIST_POISON1-stamped if not yet reused) and the iteration
walks attacker-controlled or poison memory in softirq context.

Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM):
an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET
installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged
TCP-AO segments toward its eventual 4-tuple via raw sockets, then
calls connect(). The md5-wins reconciliation in tcp_connect() fires
tcp_ao_destroy_sock(); the softirq backlog reader on the loopback
NAPI path crashes on the freed ao->head.first walk:

Oops: general protection fault, probably for non-canonical
address 0xfbd59c000000002f
KASAN: maybe wild-memory-access in range
[0xdead000000000178-0xdead00000000017f]
CPU: 0 UID: 1000 PID: 100 Comm: repro_userns
RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0
Call Trace: <IRQ>
__tcp_ao_do_lookup+0x107/0x1c0
tcp_ao_inbound_lookup.constprop.0+0x12a/0x200
tcp_inbound_ao_hash+0x5ea/0x1520
tcp_inbound_hash+0x7ce/0x1240
tcp_v4_rcv+0x1e7a/0x3e10
...

Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info
and replace the synchronous tcp_ao_info_free() with a call_rcu()
callback. Readers that captured tp->ao_info before rcu_assign_pointer
NULLed it now see the object remain valid until rcu_read_unlock().
With the patch applied the reproducer runs cleanly for 2000 iterations
on the same kernel build.
Published: 2026-07-25
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel suffered a use‑after‑free (CWE‑825) in tcp_ao_destroy_sock due to the removal of the RCU grace period. When a socket in the TCP_SYN_SENT state is destroyed, the associated TCP‑AO information may be accessed after it has been freed, leading to kernel memory corruption and a general‑protection fault. This race condition between the reader and the synchronous free can allow an attacker to trigger a crash. The flaw compromises kernel integrity and can cause a kernel crash.

Affected Systems

The defect exists in Linux kernel implementations that lack the commit restoring the RCU grace period – effectively older kernels before the r4caf12c7 patch. No precise kernel version range is listed, so any system running a pre‑patch kernel may be vulnerable. Maintaining a kernel that includes the fix or applying the patch is required to protect affected systems.

Risk and Exploitability

The EPSS score is reported as less than 1%, indicating a very low exploitation probability, and the flaw is not listed in the CISA KEV catalog. Nevertheless, the severity is high because a kernel crash can result in denial of service. The flaw is exercised by an unprivileged local user who can create a TCP socket with the TCP_AO_ADD_KEY flag, or potentially through a crafted network packet if raw sockets are permitted. Without the RCU grace period, the softirq reader can dereference a freed pointer, producing a wild‑memory‑access. The applied patch restores the grace period and replaces the synchronous free with a call_rcu, eliminating the use‑after‑free under all circumstances.

Generated by OpenCVE AI on August 4, 2026 at 14:19 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a release that contains the commit restoring the RCU grace period for tcp_ao_destroy_sock.
  • If an immediate kernel upgrade is not feasible, apply the patch that re‑adds struct rcu_head to tcp_ao_info and replaces tcp_ao_info_free() with a call_rcu() callback in the kernel source.
  • As a temporary protective measure, disable the TCP_AO_ADD_KEY/TCP_MD5SIG options or block raw socket usage in environments where these features are not required.

Generated by OpenCVE AI on August 4, 2026 at 14:19 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 01 Aug 2026 02:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Tue, 28 Jul 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References

Mon, 27 Jul 2026 05:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Sun, 26 Jul 2026 01:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 25 Jul 2026 09:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: tcp: restore RCU grace period in tcp_ao_destroy_sock Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that "the destruction of info/keys is delayed until the socket destructor" and therefore "no one can discover it anymore". That argument does not hold for the call site in tcp_connect() (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in TCP_SYN_SENT, has already been inserted into the inet ehash by inet_hash_connect() in tcp_v4_connect(), and is therefore very much discoverable: any softirq running tcp_v4_rcv() on another CPU can take the socket out of the ehash, walk into tcp_inbound_hash(), and load tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on the destroying CPU. The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208) which re-loads tp->ao_info via rcu_dereference_check(); the re-load can still observe the (about-to-be-freed) pointer because there is no synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is then walked at line 223: hlist_for_each_entry_rcu(key, &ao->head, node, ...) The writer's synchronous kfree() is free to complete between the line 218 re-fetch and the line 223 hlist iteration. The slab is reused (or simply LIST_POISON1-stamped if not yet reused) and the iteration walks attacker-controlled or poison memory in softirq context. Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM): an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged TCP-AO segments toward its eventual 4-tuple via raw sockets, then calls connect(). The md5-wins reconciliation in tcp_connect() fires tcp_ao_destroy_sock(); the softirq backlog reader on the loopback NAPI path crashes on the freed ao->head.first walk: Oops: general protection fault, probably for non-canonical address 0xfbd59c000000002f KASAN: maybe wild-memory-access in range [0xdead000000000178-0xdead00000000017f] CPU: 0 UID: 1000 PID: 100 Comm: repro_userns RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0 Call Trace: <IRQ> __tcp_ao_do_lookup+0x107/0x1c0 tcp_ao_inbound_lookup.constprop.0+0x12a/0x200 tcp_inbound_ao_hash+0x5ea/0x1520 tcp_inbound_hash+0x7ce/0x1240 tcp_v4_rcv+0x1e7a/0x3e10 ... Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info and replace the synchronous tcp_ao_info_free() with a call_rcu() callback. Readers that captured tp->ao_info before rcu_assign_pointer NULLed it now see the object remain valid until rcu_read_unlock(). With the patch applied the reproducer runs cleanly for 2000 iterations on the same kernel build.
Title tcp: restore RCU grace period in tcp_ao_destroy_sock
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:42:17.258Z

Reserved: 2026-07-19T15:36:31.789Z

Link: CVE-2026-64459

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-07-25T10:17:31.073

Modified: 2026-07-27T05:16:52.403

Link: CVE-2026-64459

cve-icon Redhat

Severity :

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64459 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-04T14:30:10Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference