CVE-2026-31472: Linux Kernel IPTFS DoS Vulnerability

CVE-2026-31472 Overview

A Denial of Service vulnerability has been discovered in the Linux kernel's XFRM (IPsec Transformations) IPTFS (IP Traffic Flow Security) subsystem. The vulnerability exists in the __input_process_payload() function which fails to properly validate inner IPv4 header length fields (tot_len and ihl) when parsing decrypted IPTFS payloads. This insufficient input validation allows attackers to craft malicious ESP (Encapsulating Security Payload) packets that cause an infinite loop in softirq context, effectively hanging the affected system.

Critical Impact
A crafted ESP packet with an inner IPv4 header containing tot_len=0 causes the kernel to enter an infinite loop in softirq context, resulting in a complete system denial of service condition that requires a hard reboot to recover.

Affected Products

Linux kernel with XFRM IPTFS support enabled
Systems processing IPsec/ESP traffic with IPTFS mode
Network appliances and VPN gateways using affected kernel versions

Discovery Timeline

2026-04-22 - CVE CVE-2026-31472 published to NVD
2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31472

Vulnerability Analysis

The vulnerability resides in the IPTFS payload processing logic within the Linux kernel's XFRM subsystem. IPTFS (IP Traffic Flow Security) is used to provide traffic flow confidentiality for IPsec connections by aggregating and fragmenting IP packets. When processing decrypted IPTFS payloads, the kernel extracts inner IP packets and processes them before they reach the standard IP receive path (ip_rcv_core()).

The root issue is that the __input_process_payload() function processes inner IPv4 packets without performing the same validation checks that the normal IP stack applies. When the inner IPv4 header's tot_len field is set to zero, the calculation for capturelen becomes min(0, remaining) = 0. This zero-length capture value means the data offset never advances during iteration, causing the while(data < tail) loop to spin indefinitely.

Root Cause

The vulnerability stems from missing input validation for inner IPv4 packet header fields in the IPTFS decryption path. Specifically:

The tot_len (total length) field is not validated to ensure it meets minimum requirements
The ihl (Internet Header Length) field is not checked against sizeof(struct iphdr)
Unlike the standard IP receive path where ip_rcv_core() performs these validations, IPTFS extracts and processes inner packets before they reach that protective layer

The fix implements validation that rejects inner IPv4 packets where tot_len < ihl*4 or ihl*4 < sizeof(struct iphdr), catching both the tot_len=0 case and malformed ihl values.

Attack Vector

An attacker with the ability to send network traffic to a system processing IPTFS-encapsulated IPsec traffic can craft a malicious ESP packet containing an inner IPv4 header with manipulated length fields. The attack requires:

Network access to the target system's IPsec/IPTFS processing path
Ability to craft and send malformed ESP packets
The target must have IPTFS mode enabled for IPsec transformations

The malicious packet triggers the infinite loop when processed, causing the system to become unresponsive as the softirq handler never completes. Since this executes in softirq context, it effectively disables network processing and can lead to a complete system hang.

The vulnerability mechanism involves the kernel's packet processing loop failing to advance through the payload buffer. When iplen is calculated as zero from the malformed tot_len field, each iteration processes zero bytes, creating an infinite loop condition that cannot be escaped through normal kernel scheduling.

Detection Methods for CVE-2026-31472

Indicators of Compromise

Sudden system unresponsiveness or hangs on systems processing IPsec/IPTFS traffic
Elevated softirq CPU usage that does not decrease
Network stack becoming completely unresponsive
Kernel watchdog triggers or NMI watchdog soft lockup warnings in system logs

Detection Strategies

Monitor for soft lockup warnings in kernel logs referencing XFRM or IPTFS functions
Implement network monitoring for malformed ESP packets with suspicious inner IP headers
Track softirq execution time anomalies that may indicate infinite loop conditions
Deploy intrusion detection signatures for ESP packets with zero-length inner IP payloads

Monitoring Recommendations

Enable kernel watchdog mechanisms to detect and report soft lockups
Configure IPsec traffic logging to capture packet metadata for forensic analysis
Implement system availability monitoring to detect sudden unresponsive states
Set up alerting on abnormal softirq CPU consumption patterns

How to Mitigate CVE-2026-31472

Immediate Actions Required

Apply the kernel patches from the official kernel git repository
Consider temporarily disabling IPTFS mode for IPsec connections if patching is not immediately possible
Implement network-level filtering to restrict sources of IPsec traffic to trusted peers
Monitor affected systems closely for signs of exploitation attempts

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix adds proper validation of inner IPv4 packet tot_len and ihl fields in the __input_process_payload() function. Patches are available through the following commits:

Organizations should update to the latest stable kernel version that includes these fixes.

Workarounds

Disable IPTFS mode for IPsec transformations and use alternative traffic flow security mechanisms
Restrict IPsec peer connections to known and trusted endpoints only
Implement strict firewall rules to limit exposure of IPsec services
Consider deploying network intrusion prevention systems capable of inspecting and filtering malformed ESP packets

bash

# Check if XFRM IPTFS is loaded/in use
lsmod | grep xfrm
cat /proc/net/xfrm_stat

# Verify kernel version and check for patches
uname -r
# Update to patched kernel version through your distribution's package manager