CVE-2026-80846: xfrm: drop ESP-in-TCP packets with no ingress device
In the Linux kernel, the following vulnerability has been resolved:
xfrm: drop ESP-in-TCP packets with no ingress device
ESP-in-TCP receives records through the TCP strparser. handleesp() restores skb->dev from the saved skbiif before passing the packet into the XFRM input path.
Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case devgetbyindexrcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device.
Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using ESP-in-TCP in the Linux kernel are exposed when queued TCP data is processed after its original ingress device has been removed, such as during veth or network-namespace teardown. Packets whose saved ingress device still exists follow the existing receive behavior.
What conditions are required to trigger the failure?
An ESP-in-TCP record must remain queued in the TCP strparser while the device identified by its saved ingress interface index is removed. When processing later resumes, the kernel cannot restore skb->dev, and the IPv4 or IPv6 XFRM input path may dereference the missing device.
What can be done if the fix cannot be applied immediately?
The provided data identifies the problematic condition as ESP-in-TCP traffic combined with ingress-device removal while TCP data is queued. Avoiding that combination, particularly teardown of veth devices or network namespaces while relevant ESP-in-TCP data may remain queued, reduces exposure.