CVE-2026-80849 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified as CVE-2024-something regarding the Linux kernel's TCP Authentication Option implementation represents a critical use-after-free flaw within the net/tcp-ao subsystem. This issue arises from improper synchronization between RCU read-side critical sections and socket state transitions during reconnection scenarios. The core of the problem lies in how tcp_inbound_ao_hash() interacts with the locking mechanisms protecting socket data structures. Specifically, this function is invoked while only an rcu_read_lock is held, prior to acquiring bh_lock_sock_nested(). In established connections where the remote peer sends a different key identifier than what is currently stored as current_key->sndid, the system looks up and updates current_key to point to the new key requested by the peer. While this lookup occurs safely within an RCU read-side context, the pointer itself persists beyond that critical section, creating a window of vulnerability if not managed correctly during state changes.
The operational impact becomes severe when a socket is disconnected and subsequently reconnected to a different peer via connect(). During this process, tcp_ao_connect_init() iterates through existing keys, unlinking any that do not match the new peer's requirements and freeing them using call_rcu(). If current_key happens to point at one of these targeted keys, it gets cleared to NULL. However, because the fast path for established sockets reads sk_state only once upon entry, a softirq interrupt can enter this code path while the socket is still in an established state. This allows the update to current_key to occur after the unlinking loop has already executed but before the RCU grace period callback frees the memory. Consequently, if the call_rcu() callback eventually executes and deallocates the key object, current_key remains pointing at that now-freed memory address rather than being properly nullified or updated in a synchronized manner.
This dangling pointer leads directly to a use-after-free condition during subsequent network operations. When the next transmission occurs, tcp_get_current_key retrieves the stale current_key pointer. Subsequently, tcp_ao_transmit_skb() attempts to read traffic key data from this freed object. Accessing memory that has been returned to the allocator pool can result in unpredictable behavior, including kernel crashes, information disclosure of sensitive cryptographic material if the memory is reused for other purposes, or potential code execution vulnerabilities depending on how the attacker manipulates the reallocated memory contents. This flaw highlights a classic race condition where asynchronous softirq processing interferes with synchronous socket state management logic.
To mitigate this vulnerability, the fix involves adjusting the timing and conditions under which keys are unlinked during reconnection. The solution requires waiting for one full RCU grace period before unlinking any key that is slated for removal. This delay ensures that all ongoing read-side critical sections have completed their execution. By the time tcp_connect() proceeds further into TCP_SYN_SENT state, where TCP_AO_ESTABLISHED does not overlap with TCPF_SYN_SENT, no new softirqs can enter the fast path logic that relies on current_key. Any softirqs already in flight will have finished processing before the grace period expires and the memory is safely freed. This approach leverages existing NULL handling mechanisms within the loop to ensure safe cleanup without introducing race conditions.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, which describes accessing memory after it has been freed, leading to undefined behavior. It also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the root cause is a failure to properly synchronize access between RCU read-side contexts and write-side modifications during socket reconfiguration. In terms of ATT&CK mapping, this could be associated with T1059 Command and Scripting Interpreter if exploited for code execution, or more broadly under privilege escalation vectors depending on kernel context. Defense-in-depth strategies should include keeping the Linux kernel updated to patch such race conditions in network stack components like TCP-AO, which are critical for securing BGP and other protocols relying on IPsec-like authentication at the transport layer.