Cloudanix VulnDB

CVE-2026-80850

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A race condition in the Linux kernel's handling of authenticated TCP connections can let memory be used after it is freed, which may crash the system under specific network setups.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in tcp_ao_info object: a race between tcp_ao_connect_init() L3-master resolution and concurrent VRF detachment allows the no-key path to call kfree() directly on tp->ao_info; a concurrent RCU reader in tcp_inbound_ao_hash() can then dereference the freed pointer.

Why it matters to the business

Systems using TCP-AO over VRF-bound interfaces risk kernel crashes or memory corruption that can cause denial of service; the window is narrow and requires specific configuration and timing, limiting widespread impact.

How an attack unfolds

An attacker in a user/network namespace configures TCP-AO keys, initiates a connect() while simultaneously detaching the veth from its VRF, causing the validation to succeed yet the later initialization to free the only key; the receive path then loads the dangling pointer under RCU and triggers the use-after-free in the hash function.

How to fix it

Apply the upstream fix that replaces the direct kfree with tcp_ao_destroy_sock() to ensure RCU-safe deferred freeing; rebuild and deploy the patched kernel on all affected systems; disable TCP-AO on VRF interfaces until patched if the feature is not required.

How to confirm the fix worked

Confirm the presence of the tcp_ao_destroy_sock() call in tcp_connect() and absence of the removed WARN_ON_ONCE; run the published namespace race reproducer and verify no KASAN reports occur; check kernel build logs or version strings for the commit that resolves the AO info lifetime issue.

Typical attack path

  1. Create user and network namespaces and attach a veth to a VRF
  2. Add a TCP-AO key via setsockopt
  3. Race connect() against VRF detachment while sending AO segments
  4. Trigger the no-key path that directly frees ao_info
  5. Have a concurrent receive path load the freed pointer under RCU

How to detect it

Search kernel logs for KASAN slab-use-after-free reports citing tcp_inbound_ao_hash; monitor for repeated no-key path executions in TCP-AO code paths combined with VRF detach events; examine audit logs for namespace-level device detach operations around TCP connect attempts.

  • BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash
  • tcp_ao_vrf_race
  • tcp_inbound_ao_hash+0x585/0x19f0
  • Write of size 8 at addr .* inside freed .* tcp_ao_info

What your security team should do

  • Prioritize kernel updates for any host exposing TCP-AO on VRF interfaces
  • Audit configurations that combine TCP-AO with VRF or L3-master changes
  • Add KASAN or kernel panic monitoring for tcp_inbound_ao_hash use-after-free signatures
  • Consider temporary TCP-AO disablement on affected interfaces until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: tcp: fix AO info use-after-free in tcp_ao_connect_init() tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling tcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that a key matches the peer and the bound device's current L3 master. tcp_ao_connect_init() later resolves the L3 master again and removes keys which do not match it. The socket lock does not stabilize the bound device's VRF membership. Detaching the device from its VRF between the initial validation and the L3-master calculation in tcp_ao_connect_init() can therefore make the validation succeed while initialization observes the default L3 domain and removes the only key. The subsequent AO lookup then fails, so the no-key path clears tp->ao_info and frees it directly. The receive path can find the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. A reader which loaded the old pointer can thus continue into tcp_inbound_ao_hash() after the direct free. The issue was found during a static audit of TCP-AO object lifetime. An unprivileged reproducer in self-created user and network namespaces raced connect() with detaching a veth from its VRF while sending TCP-AO segments. It triggered the same KASAN report on two fresh boots: BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232 Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0 Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640 Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720 The bad address is 40 bytes inside the freed 128-byte object, matching the tcp_ao_info counters.key_not_found field. The two runs used 1000 attempts each, reached the no-key path 366 and 411 times, and produced one and two KASAN reports respectively. With this change, the same reproducer reached the no-key path 366 times in 1000 attempts without a KASAN report or oops. Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info, updates the socket memory and static-key accounting, and defers the free until after an RCU grace period. Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race makes the no-key state reachable during normal operation, so it is a handled condition rather than an impossible assertion. On panic_on_warn kernels the WARN would turn this handled race into a kernel panic.

Affected packages

Ecosystem Package Introduced Fixed