CVE-2026-80846: Linux Kernel ESP-in-TCP DoS Vulnerability

CVE-2026-80846 Overview

CVE-2026-80846 is a NULL pointer dereference vulnerability in the Linux kernel's XFRM (Transform) subsystem. The flaw resides in the ESP-in-TCP receive path, where queued TCP data can be processed after the original ingress device has been removed. When dev_get_by_index_rcu() returns NULL during route lookup, the XFRM IPv4 and IPv6 input paths dereference the invalid skb->dev pointer. This condition triggers during scenarios such as veth teardown or network namespace destruction while ESP-in-TCP records remain queued in the TCP strparser.

Critical Impact
Local conditions involving network namespace or virtual ethernet device teardown can trigger a kernel NULL pointer dereference, resulting in a kernel crash and denial of service.

Affected Products

Linux kernel versions containing the ESP-in-TCP receive path via TCP strparser
Systems using XFRM IPsec with ESP encapsulated over TCP
Container and virtualization hosts using veth pairs or network namespaces with IPsec

Discovery Timeline

2026-09-04 - CVE-2026-80846 published to the National Vulnerability Database
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80846

Vulnerability Analysis

The defect exists in the handle_esp() function within the Linux kernel's XFRM subsystem. ESP-in-TCP receives records through the TCP strparser, which queues packets for later processing. Before passing packets into the XFRM input path, handle_esp() restores skb->dev from the previously saved skb_iif interface index.

When the original ingress device is removed while ESP-in-TCP data remains queued, the lookup via dev_get_by_index_rcu() returns NULL. Both the IPv4 and IPv6 XFRM input paths assume skb->dev is valid while constructing the route lookup. Dereferencing the NULL device pointer causes a kernel oops and terminates the kernel thread handling the packet.

Root Cause

The root cause is a lifetime mismatch between queued TCP data and the ingress network device. The XFRM receive path did not validate the result of the deferred device lookup before use. Packets queued in the strparser can outlive their original interface, particularly during veth teardown or network namespace destruction.

Attack Vector

Exploitation requires local conditions that trigger removal of an ingress interface while ESP-in-TCP packets remain queued. This scenario arises in containerized environments using network namespaces or virtual ethernet devices with IPsec ESP-in-TCP encapsulation. An unprivileged workload that can cause namespace teardown while ESP-in-TCP traffic is in flight may trigger the kernel crash, resulting in denial of service. Remote exploitation is not directly possible without local orchestration of the teardown event.

See the upstream fix in Kernel Commit 239d0f7 and related backports for technical details of the corrected NULL check.

Detection Methods for CVE-2026-80846

Indicators of Compromise

Kernel oops or panic messages referencing handle_esp, xfrm_input, or dev_get_by_index_rcu in dmesg output
Unexpected kernel crashes on hosts running ESP-in-TCP IPsec tunnels during container or namespace lifecycle events
Repeated soft lockups or NULL pointer dereference traces coinciding with veth interface removal

Detection Strategies

Monitor kernel logs for NULL pointer dereference stack traces originating from the XFRM input path
Correlate network namespace teardown events with kernel crash telemetry on systems using ESP-in-TCP
Audit hosts to identify workloads combining IPsec ESP-in-TCP with dynamic veth or namespace churn

Monitoring Recommendations

Ingest kernel logs into a centralized logging platform and alert on BUG: or Oops: entries referencing XFRM symbols
Track kernel version inventory across container hosts to identify systems still running vulnerable builds
Baseline ESP-in-TCP traffic patterns and alert on abnormal reset activity coincident with device removal

How to Mitigate CVE-2026-80846

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits listed in the vendor advisories
Prioritize patching for container hosts, virtualization servers, and gateways that use ESP-in-TCP IPsec
Reboot into the patched kernel to ensure the fixed XFRM input path is active

Patch Information

The fix drops packets whose saved ingress device can no longer be resolved through dev_get_by_index_rcu(). Such packets can no longer be routed through the normal XFRM receive path, and dropping them preserves existing behavior for packets whose ingress device still exists. Backported fixes are available in multiple stable tree commits, including 239d0f7, 2dd1609, 328e40a, 6af5cdb, 7911e02, 943d952, c296d25, e1d7c5a, and f00235f.

Workarounds

Disable ESP-in-TCP encapsulation where feasible and use standard ESP over UDP or IP until patches are applied
Avoid tearing down network namespaces or veth interfaces while active ESP-in-TCP flows are in progress
Restrict unprivileged access to CLONE_NEWNET and namespace management on multi-tenant hosts

bash

# Verify running kernel version and check for XFRM ESP-in-TCP usage
uname -r
ip xfrm state | grep -i 'encap.*tcp'

# After applying vendor kernel updates, reboot into the patched kernel
sudo reboot