CVE-2026-80850: Linux Kernel TCP-AO Use-After-Free Flaw

CVE-2026-80850 Overview

CVE-2026-80850 is a use-after-free vulnerability in the Linux kernel's TCP Authentication Option (TCP-AO) implementation. The flaw resides in tcp_ao_connect_init() and stems from a race between socket connect initialization and VRF (Virtual Routing and Forwarding) membership changes on the bound device.

An unprivileged local attacker operating in user and network namespaces can race connect() with detaching a veth from its VRF while sending TCP-AO segments. The race causes the kernel to free the tcp_ao_info structure while a concurrent RCU reader in the receive path is still accessing it, producing a KASAN slab-use-after-free write.

Critical Impact
Local unprivileged users in user/network namespaces can trigger kernel memory corruption in the TCP-AO code path, enabling denial of service and potential privilege escalation.

Affected Products

Linux kernel builds with TCP-AO (CONFIG_TCP_AO) enabled
Distributions shipping vulnerable stable kernel branches prior to the referenced fix commits
Systems using VRF-bound sockets with TCP Authentication Option keys

Discovery Timeline

2026-09-04 - CVE-2026-80850 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80850

Vulnerability Analysis

The vulnerability affects the connect path of TCP sockets that use TCP-AO for authenticated segments. tcp_v4_connect() inserts a SYN-SENT socket into the established hash (ehash) before invoking tcp_connect(). When TCP-AO is configured, tcp_connect() validates that a matching key exists for the peer and the bound device's current L3 master.

tcp_ao_connect_init() subsequently resolves the L3 master a second time and prunes keys that no longer match. Because the socket lock does not stabilize the VRF membership of the bound device, an attacker can detach the device from its VRF between the two lookups. The initial validation observes the VRF while the reinitialization observes the default L3 domain, causing the only matching key to be removed.

The no-key path then clears tp->ao_info and calls kfree() on it directly. Concurrently, tcp_v4_rcv() can locate the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. The reader then enters tcp_inbound_ao_hash() with a dangling pointer, producing a slab-use-after-free write at offset 40 inside the freed 128-byte object (the counters.key_not_found field of tcp_ao_info).

Root Cause

The root cause is unsynchronized L3 master resolution combined with an unsafe deallocation of an RCU-published object. The direct kfree() in the no-key path bypasses the RCU grace period that other readers rely on for safe traversal of tp->ao_info. This is a classic Use After Free triggered by a TOCTOU race between the socket lock holder and RCU readers.

Attack Vector

Exploitation requires local code execution with the ability to create user and network namespaces, which is available to unprivileged users on many default configurations. The proof-of-concept reproducer races connect() on a TCP-AO socket bound to a veth device against a VRF detach operation on that device while injecting TCP-AO segments. Reported reproduction reached the no-key path 366 and 411 times across 1000 attempts, generating one and two KASAN reports respectively.

See the upstream fix in Kernel Commit 284d7fd0eec8774 and the companion stable backports for the exact patch text.

Detection Methods for CVE-2026-80850

Indicators of Compromise

KASAN slab-use-after-free reports in tcp_inbound_ao_hash or tcp_inbound_hash in kernel logs
Kernel oops or panic traces referencing tcp_ao_connect_init, tcp_connect, or tcp_v4_connect
Repeated unprivileged creation of user and network namespaces combined with VRF manipulation on veth interfaces
Unexpected WARN_ON_ONCE() firings from the TCP-AO no-key path on unpatched kernels

Detection Strategies

Enable KASAN on test and canary systems to surface the use-after-free during fuzzing or reproducer runs
Audit kernel ring buffer output (dmesg) for TCP-AO stack traces and slab corruption reports
Monitor netlink RTM_DELLINK and VRF membership changes correlated with new TCP-AO socket creation
Track process activity that combines unshare(CLONE_NEWUSER|CLONE_NEWNET) with rapid connect() and interface manipulation

Monitoring Recommendations

Forward kernel logs to a centralized log platform and alert on KASAN, BUG, or Oops signatures
Baseline legitimate use of TCP-AO (TCP_AO_ADD_KEY setsockopt) and flag anomalous callers
Alert on unprivileged processes performing VRF enslave/unenslave operations via ip link set master

How to Mitigate CVE-2026-80850

Immediate Actions Required

Apply vendor-supplied kernel updates that include the fix commits referenced below as soon as they are available for your distribution
Restrict unprivileged user namespace creation via sysctl -w kernel.unprivileged_userns_clone=0 on distributions that expose the toggle
Disable CONFIG_TCP_AO in custom kernel builds where TCP Authentication Option is not required
Limit which users can create and manipulate VRF-bound network devices

Patch Information

The upstream fix replaces the direct kfree() in the no-key path with tcp_ao_destroy_sock(), which unpublishes the AO info, updates socket memory and static-key accounting, and defers the free until after an RCU grace period. The fix also drops the WARN_ON_ONCE() because the VRF detach race makes the no-key state reachable during normal operation. Stable backports are available in the following commits:

Workarounds

Disable unprivileged user namespaces to remove the primary path for unprivileged attackers to reach the vulnerable code
Avoid dynamic VRF membership changes on interfaces hosting TCP-AO-authenticated sessions
On panic_on_warn kernels, remove that setting only after patching, since the pre-patch WARN_ON_ONCE() in the no-key path could otherwise convert this race into a kernel panic

bash

# Reduce attack surface on unpatched systems
sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> /etc/sysctl.d/99-hardening.conf

# Verify running kernel version against fixed stable branches
uname -r