CVE-2026-31684: Linux Kernel VLAN Header Vulnerability

CVE-2026-31684 Overview

A vulnerability has been resolved in the Linux kernel's network traffic control subsystem, specifically within the act_csum (checksum action) module. The tcf_csum_act() function walks nested VLAN headers directly from skb->data when a socket buffer (skb) still carries in-payload VLAN tags. The flaw occurs because the code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area of the buffer.

If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the subsequent skb_pull(VLAN_HLEN) operation may violate skb invariants, potentially leading to memory corruption or system instability.

Critical Impact
Improper validation of nested VLAN headers in the Linux kernel's traffic control subsystem can lead to out-of-bounds memory access and potential violation of socket buffer invariants, affecting system stability.

Affected Products

Linux Kernel (multiple stable branches)

Discovery Timeline

2026-04-25 - CVE CVE-2026-31684 published to NVD
2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-31684

Vulnerability Analysis

This vulnerability affects the checksum action module (act_csum) within the Linux kernel's traffic control (tc) subsystem. The core issue stems from insufficient bounds checking when processing nested VLAN (Virtual LAN) headers in network packets.

When handling packets with multiple VLAN tags (QinQ or stacked VLAN configurations), the tcf_csum_act() function iterates through nested VLAN headers to recalculate checksums. The function directly accesses vlan->h_vlan_encapsulated_proto to determine the encapsulated protocol type and subsequently calls skb_pull() to advance past each VLAN header.

The vulnerability arises because the code fails to verify that the complete VLAN header (VLAN_HLEN bytes, typically 4 bytes) is available in the linear portion of the socket buffer before attempting to access or pull the data. In scenarios where packet data is fragmented across multiple memory regions (non-linear skb), only a partial VLAN header may be present in the directly accessible linear area.

Root Cause

The root cause is a missing call to pskb_may_pull() before accessing nested VLAN header fields. The pskb_may_pull() function is a critical Linux kernel networking primitive that ensures a specified number of bytes are available in the linear data area of a socket buffer, pulling data from fragment pages if necessary.

Without this validation, the code assumes the full VLAN header is always linearly accessible, which is not guaranteed for fragmented or non-linear packets. This leads to:

Out-of-bounds read: Accessing h_vlan_encapsulated_proto when the field is not fully linearized
SKB invariant violation: Calling skb_pull() without proper buffer validation can corrupt the socket buffer state

Attack Vector

The vulnerability can be triggered when processing network packets with nested VLAN headers through the traffic control subsystem where the act_csum action is configured. An attacker capable of sending crafted packets with malformed or specially structured VLAN tags to a system using tc filters with checksum actions could potentially trigger this condition.

The attack requires:

Network access to send packets to the target system
The target system must have traffic control rules configured with the act_csum action
Packets must contain nested VLAN headers in a configuration that results in partial linearization

The vulnerability mechanism involves improper validation of VLAN header boundaries in the tcf_csum_act() function. When processing nested VLAN tags, the function reads protocol type fields and pulls header bytes without first calling pskb_may_pull(skb, VLAN_HLEN) to ensure the complete header is available in the linear buffer area. Technical details are available in the kernel git commits referenced below.

Detection Methods for CVE-2026-31684

Indicators of Compromise

Unexpected kernel panics or oops messages referencing tcf_csum_act or act_csum
System instability when processing high volumes of VLAN-tagged traffic
Kernel log entries indicating skb corruption or invalid memory access in networking code

Detection Strategies

Monitor kernel logs (dmesg, /var/log/kern.log) for memory access violations in the traffic control subsystem
Deploy kernel-level monitoring to detect anomalous behavior in the net/sched/act_csum.c module
Use network monitoring to identify unusual patterns of VLAN-tagged traffic targeting systems with tc filters

Monitoring Recommendations

Enable kernel address sanitizer (KASAN) in development environments to detect out-of-bounds memory access
Configure auditd rules to log traffic control configuration changes
Implement network segmentation to limit exposure of systems running vulnerable kernel versions

How to Mitigate CVE-2026-31684

Immediate Actions Required

Update the Linux kernel to a patched version that includes the validation fix
Review traffic control configurations and temporarily disable act_csum actions on systems processing untrusted VLAN-tagged traffic
Monitor affected systems for signs of exploitation or instability

Patch Information

The fix requires pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header is not fully available after the pull attempt, the packet is dropped through the existing error path. Patches have been committed to multiple stable kernel branches:

Workarounds

Remove or disable act_csum actions from traffic control filters on affected systems until patches can be applied
Implement network-level filtering to drop malformed VLAN-tagged packets before they reach vulnerable systems
Use network segmentation to isolate systems that must process VLAN-tagged traffic from untrusted network segments

bash

# Check for act_csum usage in traffic control rules
tc filter show dev eth0

# Temporarily remove act_csum actions (example)
tc filter del dev eth0 parent 1:0 protocol 802.1Q