CVE-2026-31421: Linux Kernel cls_fw NULL Pointer Vulnerability

CVE-2026-31421 Overview

A NULL pointer dereference vulnerability has been discovered in the Linux kernel's network traffic control subsystem, specifically within the cls_fw (firewall classifier) module. The vulnerability exists in the fw_classify() function when processing packets on shared blocks with empty cls_fw filters attached.

When a shared block configuration is used, the block->q pointer remains NULL. The legacy classification path in fw_classify() calls tcf_block_q() and attempts to dereference q->handle, resulting in a NULL pointer dereference when a packet with a nonzero major skb mark is classified through an empty cls_fw filter attached to the shared block.

Critical Impact

Exploitation of this vulnerability can cause kernel crashes and denial of service conditions on affected Linux systems utilizing traffic control shared blocks with cls_fw filters.

Affected Products

• Linux Kernel (multiple stable versions)
• Systems using net/sched Traffic Control subsystem
• Configurations utilizing shared blocks with cls_fw classifier

Discovery Timeline

• April 13, 2026 - CVE-2026-31421 published to NVD
• April 13, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31421

Vulnerability Analysis

The vulnerability resides in the firewall classifier module (net/sched/cls_fw.c) of the Linux kernel's traffic control subsystem. The issue manifests when the legacy classification method is invoked on shared block configurations.

Shared blocks in the Linux traffic control subsystem are designed to allow multiple qdiscs (queueing disciplines) to share the same set of filters. However, unlike traditional block configurations where block->q points to the associated qdisc, shared blocks intentionally leave block->q as NULL since they can be attached to multiple qdiscs simultaneously.

The fw_classify() function contains a legacy code path that assumes block->q is always valid. When processing packets through this path, the function calls tcf_block_q() to retrieve the qdisc pointer and then accesses q->handle. This creates a NULL pointer dereference vulnerability when:

1. An empty cls_fw filter is attached to a shared block
2. A packet with a nonzero major skb mark enters the classification path
3. The legacy classification method is triggered

The KASAN (Kernel Address SANitizer) report identifies the crash occurring at memory range [0x0000000000000038-0x000000000000003f], which corresponds to the offset of the handle field within the qdisc structure.

Root Cause

The root cause is insufficient validation in the fw_classify() function's legacy code path. The function fails to verify that block->q is non-NULL before dereferencing it. This oversight becomes exploitable when shared blocks are used, as they deliberately maintain a NULL block->q pointer.

The fix introduces validation in fw_change() to reject configurations that attempt to use the old method (without TCA_OPTIONS) on shared blocks, since the fw_classify() legacy path requires a valid block->q pointer that shared blocks cannot provide.

Attack Vector

The vulnerability can be triggered through local access by:

1. Creating a shared block configuration in the traffic control subsystem
2. Attaching an empty cls_fw filter to the shared block without specifying TCA_OPTIONS
3. Sending network traffic that triggers packet classification with a nonzero major skb mark

The attack call trace follows this path:

fw_classify (net/sched/cls_fw.c:81)
  └─> tcf_classify (net/sched/cls_api.c:1764, 1860)
        └─> tc_run (net/core/dev.c:4401)
              └─> __dev_queue_xmit (net/core/dev.c:4535, 4790)

Detection Methods for CVE-2026-31421

Indicators of Compromise

• Kernel panic or oops messages referencing fw_classify in net/sched/cls_fw.c
• KASAN reports indicating NULL pointer dereference in range 0x0000000000000038-0x000000000000003f
• System crashes during network traffic processing on systems using shared block configurations

Detection Strategies

• Monitor kernel logs for NULL pointer dereference errors originating from the cls_fw module
• Deploy KASAN-enabled kernels in test environments to detect exploitation attempts
• Audit traffic control configurations for shared blocks using cls_fw classifiers without TCA_OPTIONS

Monitoring Recommendations

• Enable kernel logging and monitor for oops/panic events in the net/sched subsystem
• Implement crash dump collection to capture kernel state during exploitation attempts
• Review traffic control configurations periodically for potentially vulnerable setups

How to Mitigate CVE-2026-31421

Immediate Actions Required

• Apply the kernel patches to affected systems immediately
• Review and audit existing traffic control configurations using shared blocks
• Consider temporarily avoiding cls_fw filters on shared blocks until patches are applied
• Monitor systems for signs of exploitation or unexpected crashes

Patch Information

The Linux kernel maintainers have released patches across multiple stable branches. The fix modifies fw_change() to reject legacy method configurations (without TCA_OPTIONS) when applied to shared blocks.

Patches are available via the following kernel git commits:

• Kernel Git Commit 18328eff
• Kernel Git Commit 3cb055df
• Kernel Git Commit 3d41f9a3
• Kernel Git Commit 5cf41031
• Kernel Git Commit 96426c34
• Kernel Git Commit faeea8bb

Workarounds

• Avoid using cls_fw filters on shared blocks until patches are deployed
• Use alternative classifiers (such as cls_flower or cls_u32) for shared block configurations
• Ensure all cls_fw filter configurations include proper TCA_OPTIONS attributes

# Check for potentially vulnerable configurations
# List all shared blocks and their attached filters
tc filter show block

# Review cls_fw filter usage
tc filter show | grep fw

# Alternative: Use cls_flower instead of cls_fw on shared blocks
tc filter add block 1 flower action drop