Cloudanix VulnDB

CVE-2026-80849

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's secure connection handling can let an attacker crash servers or potentially take them over by forcing rapid connection changes.

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 handling: current_key pointer is updated under RCU read lock on the fast path but can outlive the grace period when tcp_ao_connect_init frees keys on reconnect; subsequent tcp_get_current_key and tcp_ao_transmit_skb dereference the freed object.

Why it matters to the business

Linux systems using TCP-AO can experience kernel crashes, memory corruption, or potential local privilege escalation during connection re-establishment to a different peer, disrupting network services and requiring urgent patching.

How an attack unfolds

An attacker initiates a TCP-AO connection, then forces a disconnect and reconnect to a different peer while a softirq is still executing the fast path; the race allows current_key to reference memory freed by call_rcu, which tcp_ao_transmit_skb later reads to trigger the use-after-free.

How to fix it

Apply the upstream fix that waits one RCU grace period before unlinking non-matching keys in tcp_ao_connect_init; rebuild and deploy the patched kernel; disable TCP-AO on affected interfaces until patched if immediate upgrade is not feasible.

How to confirm the fix worked

Confirm the kernel source contains the added rcu_barrier or synchronize_rcu call before key unlinking in tcp_ao_connect_init; run regression tests exercising reconnect scenarios with TCP-AO enabled; verify sk_state checks prevent fast-path entry after the wait.

Typical attack path

  1. Establish TCP-AO connection with the target
  2. Trigger socket disconnect and reconnect to a different peer address
  3. Race the RCU grace period with an inbound packet that updates current_key
  4. Cause a subsequent transmission that calls tcp_get_current_key on the dangling pointer
  5. Read traffic key material from freed memory leading to crash or corruption

How to detect it

Inspect kernel logs for oops/panic mentioning tcp_ao or use-after-free; correlate with TCP-AO socket state changes and reconnect events; look for processes triggering connect() on AO-enabled sockets shortly before crashes.

What your security team should do

  • Prioritize kernel upgrade on all systems exposing TCP-AO sockets
  • Monitor for kernel oops or panic logs containing tcp_ao_transmit_skb or tcp_get_current_key
  • Temporarily disable TCP-AO authentication where business risk allows
  • Review downstream package updates once distributions release fixed kernels

The record

In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of current_key on reconnect to another peer tcp_inbound_ao_hash() is called before bh_lock_sock_nested() is taken, with only rcu_read_lock() held. On the fast path for established sockets, if the rnext_keyid sent by the peer differs from current_key->sndid, the key the peer asked for is looked up and stored in current_key. The lookup is inside the RCU read side, but current_key outlives it. When the socket is disconnected and connect() is called again for another peer, tcp_ao_connect_init() unlinks every key that does not match the new peer and frees it with call_rcu(). If current_key points at such a key, it is cleared to NULL. The fast path reads sk_state only once on entry, so a softirq that got into it while the socket was still established can update current_key after that loop has already run. The update is inside the RCU read side, so it comes before the call_rcu() callback, and once the callback frees the key, current_key is left pointing at freed memory. The next transmission picks that pointer up in tcp_get_current_key(). tcp_ao_transmit_skb() then reads the traffic key from the freed object, which is the use-after-free. Wait for one grace period before unlinking, and only if a key is going to be removed. By the time tcp_connect() runs the socket is already in TCP_SYN_SENT, and TCP_AO_ESTABLISHED does not contain TCPF_SYN_SENT, so a softirq entering after the wait cannot reach the fast path, and the ones already in it have finished. The existing NULL handling in the loop is then enough.

Affected packages

Ecosystem Package Introduced Fixed