CVE-2026-31422: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-31422 Overview

A NULL pointer dereference vulnerability has been discovered in the Linux kernel's traffic control classifier (cls_flow). The vulnerability exists in the flow_change() function within net/sched/cls_flow.c, where the code calls tcf_block_q() and dereferences q->handle to derive a default baseclass. When operating on shared blocks, block->q is left NULL, resulting in a NULL pointer dereference when a flow filter without a fully qualified baseclass is created.

Critical Impact

Local attackers with network configuration privileges can trigger a kernel panic via NULL pointer dereference, causing denial of service conditions on affected Linux systems.

Affected Products

• Linux kernel (versions with vulnerable cls_flow implementation)
• Linux-based systems using traffic control shared blocks
• Network appliances and containers leveraging tc filter configurations

Discovery Timeline

• 2026-04-13 - CVE-2026-31422 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-31422

Vulnerability Analysis

This vulnerability is a Null Pointer Dereference in the Linux kernel's network scheduler subsystem. The flow_change() function in net/sched/cls_flow.c assumes that block->q will always contain a valid pointer when dereferencing q->handle to compute a default baseclass value. However, shared blocks are designed to be detached from a specific qdisc, meaning block->q is intentionally NULL in these configurations.

When an administrator or automated process attempts to create a flow filter on a shared block without specifying a fully qualified baseclass, the code path leads to dereferencing the NULL block->q pointer. This triggers a kernel KASAN (Kernel Address Sanitizer) null-pointer-deref error, as shown in the crash trace at memory range 0x0000000000000038-0x000000000000003f.

The call trace indicates the vulnerability is triggered through the netlink-based traffic control interface via tc_new_tfilter() and rtnetlink_rcv_msg(), making it exploitable through standard tc commands or programmatic netlink access.

Root Cause

The root cause is a missing validation check for shared blocks in the flow_change() function. The code unconditionally accesses block->q->handle without first verifying whether the block is shared (and therefore has a NULL q pointer). The fix introduces a tcf_block_shared() check before accessing block->q and returns -EINVAL for shared blocks, preventing the NULL dereference.

Attack Vector

The vulnerability can be exploited locally by an attacker with sufficient privileges to configure traffic control filters. This typically requires CAP_NET_ADMIN capabilities or root access. The attacker would create a shared traffic control block and then attempt to add a flow filter without specifying a complete baseclass specification.

The exploitation path follows the sequence:

1. Create a shared tc block using the tc utility or netlink API
2. Attempt to add a flow classifier filter on the shared block without a fully qualified baseclass
3. The flow_change() function is invoked via tc_new_tfilter()
4. The code dereferences block->q which is NULL for shared blocks
5. Kernel panic or denial of service occurs

Detection Methods for CVE-2026-31422

Indicators of Compromise

• Kernel crash logs containing null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
• KASAN error messages referencing flow_change in net/sched/cls_flow.c:508
• System crashes occurring during traffic control configuration operations
• Call traces showing tc_new_tfilter → rtnetlink_rcv_msg sequences preceding crashes

Detection Strategies

• Monitor kernel logs (dmesg) for KASAN null-pointer-deref errors in cls_flow.c
• Implement audit logging for tc filter commands targeting shared blocks
• Deploy kernel crash dump analysis to identify cls_flow-related panics
• Use SentinelOne Singularity Platform to detect anomalous kernel behavior patterns

Monitoring Recommendations

• Enable kernel KASAN in development/testing environments to catch null dereference attempts
• Configure kdump or similar crash dump mechanisms to capture diagnostic data
• Monitor netlink traffic for suspicious tc filter creation patterns on shared blocks
• Implement system health checks to detect repeated kernel panic/reboot cycles

How to Mitigate CVE-2026-31422

Immediate Actions Required

• Update to a patched Linux kernel version as soon as available
• Restrict CAP_NET_ADMIN capabilities to essential services and trusted users only
• Audit systems for any automated scripts creating tc filters on shared blocks
• Consider temporarily disabling shared block usage if not operationally required

Patch Information

Multiple patches have been released across various stable kernel branches to address this vulnerability. The fix adds a tcf_block_shared() check before accessing block->q and returns -EINVAL when attempting to create flow filters on shared blocks without a fully qualified baseclass.

Available patches:

• Kernel Patch Commit 1a280dd
• Kernel Patch Commit 415ea0c
• Kernel Patch Commit 4a09f72
• Kernel Patch Commit 9bf5fc3
• Kernel Patch Commit a208c3e
• Kernel Patch Commit cc707a4

Workarounds

• Restrict access to traffic control configuration using Linux capabilities (CAP_NET_ADMIN)
• Avoid using shared tc blocks if operationally feasible until patches are applied
• Use SELinux or AppArmor policies to limit processes that can invoke tc filter operations
• Implement network namespace isolation to contain potential crash impact

# Restrict CAP_NET_ADMIN capability to specific binaries only
# Remove from non-essential users and services
setcap -r /usr/sbin/tc  # Remove ambient capability if not needed
chmod 750 /usr/sbin/tc  # Restrict tc binary access to root/admin group