CVE-2026-31684

What it actually does

This flaw is an out-of-bounds read and packet-buffer state violation in the Linux kernel traffic-control checksum action path, specifically in net/sched act_csum handling of nested in-payload VLAN headers. When a socket buffer contains partially linearized nested VLAN tags, the kernel may read the encapsulated protocol field before confirming the full VLAN header is present in the linear area, then attempt to pull bytes from the buffer in a way that violates skb invariants. A local attacker with sufficient privileges to create or influence traffic-control rules and deliver crafted VLAN-encapsulated packets can trigger a kernel fault or panic, causing denial of service. The issue does not indicate direct confidentiality or integrity impact, but it can affect system availability.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems that process crafted traffic through vulnerable traffic-control checksum actions, potentially interrupting network services, packet forwarding, container networking, virtualized networking, or host availability. The CVSS score indicates moderate severity, EPSS is very low and stable, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely at this time; however, systems relying heavily on Linux traffic control, VLAN processing, or multi-tenant local access should treat it as an availability risk.

How an attack unfolds

An attacker first needs local privileges sufficient to configure or influence Linux traffic-control behavior, such as adding a tc filter/action that invokes the checksum action on packets. The attacker then causes the system to process a crafted packet containing nested VLAN headers where an inner VLAN header is only partially present in the skb linear data area. During checksum action processing, the vulnerable kernel code walks the VLAN headers directly from skb data, reads the nested VLAN protocol field without first ensuring the complete VLAN header is available, and then pulls VLAN header bytes. This can cause an out-of-bounds read or violate kernel socket-buffer invariants, resulting in a kernel warning, BUG, panic, or networking subsystem crash. The practical result is denial of service rather than code execution based on the available information.

How to fix it

Upgrade the Linux kernel to a vendor-maintained release that includes the fix for act_csum nested VLAN header validation. The fix requires checking that a full VLAN header is available with pskb_may_pull() before reading or pulling each nested VLAN header, and dropping packets through the existing error path when the header cannot be safely accessed. Because no exact fixed package versions were provided, use the fixed kernel versions published by the operating-system, appliance, container-host, hypervisor, or embedded Linux vendor. Where immediate patching is not possible, reduce exposure by limiting local administrative access, restricting the ability to create traffic-control qdisc/filter/action rules, disabling unneeded tc checksum actions, avoiding untrusted local packet-generation workloads, and monitoring systems that process VLAN-tagged or nested VLAN traffic.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that the system has rebooted into the patched kernel, not merely installed it. Review vendor advisories or changelogs for the act_csum nested VLAN validation fix in net/sched. On systems where source or symbols are available, validate that the act_csum VLAN-walking path checks pskb_may_pull(skb, VLAN_HLEN) before reading h_vlan_encapsulated_proto or pulling VLAN_HLEN bytes for each nested VLAN header. Operationally, inventory use of tc actions with commands such as `tc filter show` and `tc actions ls action csum`, and confirm vulnerable hosts no longer run unpatched kernels. Avoid destructive proof-of-concept testing on production systems because successful validation could crash the kernel.

Typical attack path

1. Obtain local access with privileges that allow configuring Linux traffic-control rules or otherwise influencing packet processing paths that use the act_csum action.
2. Configure a traffic-control filter/action path that applies checksum recalculation to relevant packets.
3. Generate or inject crafted traffic containing nested VLAN tags with an inner VLAN header split or only partially present in the skb linear area.
4. Trigger the vulnerable act_csum VLAN parsing path during packet processing.
5. Cause the kernel to read beyond the linear skb area or pull insufficient data, leading to a kernel fault, BUG, panic, or networking disruption.

How to detect it

Look for evidence of kernel faults or panics occurring during traffic-control checksum processing or VLAN packet handling. Primary log sources include kernel ring buffer output, system journal, syslog, crash dumps, kdump/vmcore artifacts, endpoint telemetry for privileged `tc` usage, audit logs for CAP_NET_ADMIN activity, and container/runtime logs showing privileged network namespace operations. Search for kernel messages referencing `act_csum`, `tcf_csum_act`, `skb_pull`, `pskb_may_pull`, `VLAN_HLEN`, `8021q`, nested VLAN handling, or socket-buffer warnings immediately before a reboot, panic, soft lockup, or network outage. Also review command execution logs for creation or modification of traffic-control filters/actions using `csum`, especially when followed by crafted VLAN traffic generation tools or unexplained crashes. No named threat actors or ransomware campaigns are reported for this issue, so detection should focus on local privilege misuse, suspicious tc configuration changes, and kernel crash artifacts rather than actor-specific infrastructure.

• tcf_csum_act
• act_csum
• skb_pull
• pskb_may_pull
• VLAN_HLEN
• h_vlan_encapsulated_proto
• skb_under_panic
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• WARNING: CPU:
• net/sched/act_csum.c
• tc actions ls action csum
• tc filter show
• action csum
• CAP_NET_ADMIN
• 8021q
• 802.1Q
• QinQ

What your security team should do

• Prioritize patching Linux systems that allow local users, containers, network namespaces, virtualization workloads, or automation to configure traffic-control rules.
• Confirm affected systems have rebooted into the fixed kernel after package installation.
• Restrict use of `tc`, CAP_NET_ADMIN, privileged containers, and network namespace administration to trusted administrators and workloads only.
• Inventory systems using VLAN, QinQ, software bridging, routing, container networking, or advanced Linux traffic shaping where act_csum may be present.
• Monitor kernel logs for crashes, warnings, or BUG messages involving act_csum, tcf_csum_act, skb_pull, pskb_may_pull, VLAN parsing, or socket-buffer invariant violations.
• Treat unexplained host reboots or kernel panics on systems processing VLAN-tagged traffic as potential exploitation or stability indicators and preserve logs for forensics.
• Because EPSS is very low, KEV is false, and no public exploit maturity is reported, balance urgency against higher-risk vulnerabilities, but do not defer patching on multi-user or multi-tenant Linux hosts.