CVE-2026-80848: Linux Kernel espintcp Race Condition Flaw

CVE-2026-80848 Overview

CVE-2026-80848 is a use-after-free (UAF) vulnerability in the Linux kernel's xfrm subsystem, specifically in the espintcp code path that handles Encapsulating Security Payload (ESP) over TCP. The Zero Day Initiative (ZDI) reported and analyzed a race condition triggered during socket close. The espintcp_close() function frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue can invoke esp_output_tcp_finish(), which reads the same socket buffer as a data source. The resulting race allows kernel memory to be accessed after it has been freed.

Critical Impact
A race window during espintcp socket teardown allows concurrent kernel worker threads to read a freed sk_buff, producing a kernel-space use-after-free that may lead to memory corruption or local privilege escalation.

Affected Products

Linux kernel builds with CONFIG_XFRM and espintcp (ESP-in-TCP) support enabled
Distributions shipping affected upstream kernels prior to the patch commits referenced by kernel.org
IPsec deployments that transport ESP over TCP using the espintcp socket family

Discovery Timeline

Vulnerability reported and analyzed by the Zero Day Initiative (ZDI)
2026-09-04 - CVE-2026-80848 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80848

Vulnerability Analysis

The defect lives in the espintcp implementation used by the Linux XFRM framework to tunnel IPsec ESP traffic inside TCP connections. Two kernel code paths access the same emsg->skb object without adequate synchronization. On the teardown path, espintcp_close() releases the queued socket buffer with kfree_skb() and does not take the socket lock. On the transmit path, the xfrm_trans_reinject workqueue reaches esp_output_tcp_finish(), which calls espintcp_push_skb() and then espintcp_push_msgs() before invoking skb_send_sock_locked() on the same buffer.

Because the two paths race, the worker can dereference an sk_buff that the close path has already freed. This is a classic time-of-check to time-of-use race producing a use-after-free in kernel memory. The fix adds a synchronize_rcu() call after resetting sk_prot. Since esp_output_tcp_finish() runs under RCU, it will not operate on a socket whose sk_prot still points to &tcp_prot once the grace period elapses.

Root Cause

The root cause is missing synchronization between the socket close path and an asynchronous RCU-scheduled work item that operates on socket-owned buffers. Simply taking the socket lock in espintcp_close() was rejected because esp_output_tcp_finish() could re-enqueue an sk_buff into the slot that was just freed, producing a memory leak instead of the UAF.

Attack Vector

Exploitation requires a local attacker capable of driving espintcp socket lifecycle events while ESP-over-TCP traffic is in flight through the xfrm_trans_reinject workqueue. Winning the race yields kernel-space use-after-free conditions, which are commonly leveraged for privilege escalation or denial of service on affected kernels.

No verified public proof-of-concept is available. See the Linux Kernel Commit ed5d9102 and related stable-tree commits for the exact code changes.

Detection Methods for CVE-2026-80848

Indicators of Compromise

Kernel oops or panic messages referencing espintcp_close, esp_output_tcp_finish, espintcp_push_msgs, or skb_send_sock_locked in dmesg or journalctl -k output.
KASAN (Kernel Address Sanitizer) reports flagging use-after-free reads inside XFRM ESP-in-TCP code paths.
Unexpected crashes on hosts terminating IPsec tunnels that transport ESP over TCP.

Detection Strategies

Inventory Linux hosts and identify kernel versions with XFRM ESP-in-TCP support that predate the fix commits referenced by the Linux Kernel Commit 24efebec series.
Correlate kernel crash telemetry with IPsec workloads to spot repeated faults in xfrm symbols.
Track process behavior that repeatedly opens and closes espintcp sockets under load, which is characteristic of race-condition exploitation attempts.

Monitoring Recommendations

Forward dmesg, /var/log/kern.log, and systemd-journal kernel facility events to a central analytics platform for search and alerting on XFRM-related stack traces.
Enable kernel crash dump collection (kdump) so post-mortem analysis can confirm UAF root cause when panics occur.
Alert on IPsec tunnel flapping combined with kernel warnings, which may indicate an attacker probing the race window.

How to Mitigate CVE-2026-80848

Immediate Actions Required

Apply the upstream fix by upgrading to a kernel that includes the espintcp UAF patch series referenced on kernel.org.
Prioritize patching hosts that terminate IPsec ESP-over-TCP tunnels, including VPN concentrators and gateways.
Restrict local user access on affected systems until the patched kernel is deployed and the host has been rebooted.

Patch Information

The upstream fix adds synchronize_rcu() after resetting sk_prot in espintcp_close() so that RCU-scheduled callers such as esp_output_tcp_finish() cannot operate on a socket whose protocol handlers still reference &tcp_prot. After this change the previously required barrier() is removed. The patch has been backported across multiple stable trees. Relevant commits include Linux Kernel Commit 24efebec, Linux Kernel Commit 29121c5e, Linux Kernel Commit 4b31a875, Linux Kernel Commit 4bc0dfa2, Linux Kernel Commit 54b41ad1, Linux Kernel Commit deb232e8, Linux Kernel Commit eb3bbf29, Linux Kernel Commit ed5d9102, and Linux Kernel Commit ff8dd7a9.

Workarounds

Disable ESP-over-TCP transport where operationally feasible and route IPsec traffic over standard ESP or IKEv2/UDP encapsulation until the patched kernel is deployed.
Reduce local attack surface by removing shell access for untrusted users on IPsec gateways.
Unload or blacklist XFRM ESP-in-TCP functionality on systems that do not require it, then reboot to ensure the code path is not reachable.

bash

# Verify current kernel version and confirm the patched build is in place after upgrade
uname -r

# Example: inspect whether espintcp is compiled into the running kernel
zgrep -E 'CONFIG_XFRM|CONFIG_INET_ESPINTCP' /proc/config.gz 2>/dev/null || \
  grep -E 'CONFIG_XFRM|CONFIG_INET_ESPINTCP' /boot/config-$(uname -r)

# Reboot into the patched kernel
sudo reboot