Cloudanix VulnDB

CVE-2026-80846

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux network encryption handling could let an attacker crash systems when certain network devices are removed while encrypted traffic is still being processed.

Exploitation
Other
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in XFRM IPv4 and IPv6 input paths when handle_esp() restores skb->dev from a stale skb_iif whose device has been removed during veth or netns teardown, allowing queued ESP-in-TCP strparser records to reach route lookup with a NULL device pointer.

Why it matters to the business

Low-probability kernel panic or denial-of-service in Linux systems using ESP-in-TCP encapsulation with virtual interfaces or network namespaces; stable low exploit probability and absence from known exploitation lists reduce immediate operational urgency despite 25 days of public disclosure.

How an attack unfolds

An attacker sends ESP-in-TCP records that queue in the TCP strparser, then forces ingress device removal (for example via namespace teardown); when the strparser later invokes handle_esp() the saved index yields no device, causing the XFRM receive path to dereference NULL while building route lookups.

How to fix it

Apply the upstream kernel patch that adds an explicit check in handle_esp() to drop packets whose saved ingress index no longer resolves via dev_get_by_index_rcu(); rebuild and deploy the fixed kernel across affected Linux distributions.

How to confirm the fix worked

Confirm the fix is present by inspecting the xfrm code for the new NULL-device check before XFRM input; reproduce device teardown while ESP-in-TCP traffic is queued and verify packets are dropped rather than causing a crash.

Typical attack path

  1. Establish ESP-in-TCP session so records flow through the TCP strparser
  2. Trigger removal of the original ingress device (veth deletion or netns teardown)
  3. Allow queued strparser data to reach handle_esp() after device removal
  4. Observe NULL dereference during XFRM IPv4/IPv6 input route construction

How to detect it

Review kernel logs for NULL pointer dereference oops in xfrm or esp code paths coinciding with veth or network namespace removal events; examine strparser and xfrm receive tracepoints for packets processed after device deletion.

What your security team should do

  • Prioritize kernel updates on systems actively using ESP-in-TCP or frequent namespace/veth operations
  • Monitor EPSS trend and KEV status for any future increase in exploit maturity
  • Test the patched kernel under simulated teardown conditions before broad rollout

The record

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. handle_esp() restores skb->dev from the saved skb_iif 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 dev_get_by_index_rcu() 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 packages

Ecosystem Package Introduced Fixed