CVE-2026-31424: Linux Kernel Netfilter DoS Vulnerability

CVE-2026-31424 Overview

A null pointer dereference vulnerability has been discovered in the Linux kernel's netfilter x_tables subsystem. The flaw exists in the xt_check_match and xt_check_target extension validation logic, which incorrectly allows NFPROTO_UNSPEC registered matches and targets to be loaded by the ARP protocol family through nft_compat. Due to a mismatch between ARP hook semantics and the NF_INET_* hook constants used for validation, matches can incorrectly pass hook validation and execute on ARP chains where fundamental hook assumptions do not hold, leading to kernel panic conditions.

Critical Impact

This vulnerability allows local attackers to trigger a kernel panic through null pointer dereference in the netfilter subsystem, causing complete system denial of service. The xt_devgroup match is one concrete example that can be exploited when loaded on ARP chains.

Affected Products

• Linux kernel (multiple versions with netfilter x_tables support)
• Systems using nft_compat with arptables integration
• Linux distributions with netfilter/iptables-nft tooling

Discovery Timeline

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

Technical Details for CVE-2026-31424

Vulnerability Analysis

The vulnerability stems from an architectural mismatch between how different protocol families define their netfilter hooks. When xt_match and xt_target structures are registered with NFPROTO_UNSPEC, they can be loaded by any protocol family via nft_compat. These extensions often use a .hooks bitmask to restrict which hooks they may execute on, with the bitmask values derived from NF_INET_* constants.

This design works correctly for protocol families that share the same five-hook layout as INET (PRE_ROUTING, LOCAL_IN, FORWARD, LOCAL_OUT, POST_ROUTING). However, ARP only defines three hooks with entirely different semantics: IN=0, OUT=1, and FORWARD=2. The collision occurs because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, causing the hook validation to silently pass for incorrect reasons.

When matches like xt_devgroup execute on ARP chains, they expect state->in to be set (as it would be on an input hook in INET context), but this assumption fails in the ARP context. The resulting null pointer dereference triggers a kernel panic with the call trace progressing through devgroup_mt → nft_match_eval → nft_do_chain → nft_do_chain_arp → nf_hook_slow → arp_xmit.

Root Cause

The root cause is insufficient protocol family validation in the x_tables extension loading mechanism. The xt_check_match and xt_check_target functions do not properly restrict NFPROTO_UNSPEC extensions from being loaded by protocol families with incompatible hook layouts. The ARP family's three-hook system with different semantic meanings was not accounted for when allowing universal extension loading.

Attack Vector

An attacker with local access and sufficient privileges to manipulate netfilter rules (typically root or CAP_NET_ADMIN capability) can craft arptables rules that load incompatible matches or targets. When these rules are evaluated during ARP packet processing, the kernel attempts to access memory through null pointers, triggering a general protection fault and subsequent kernel panic.

The exploitation path involves:

1. Loading an NFPROTO_UNSPEC registered match (such as xt_devgroup) into an arptables chain
2. Triggering ARP packet processing that invokes the loaded match
3. The match code accesses state->in expecting a valid network device pointer
4. A null pointer dereference occurs, causing kernel panic

Detection Methods for CVE-2026-31424

Indicators of Compromise

• Kernel panic logs containing "general protection fault" with RIP pointing to devgroup_mt or similar x_tables match functions
• Call traces showing nft_match_eval → nft_do_chain → nft_do_chain_arp → nf_hook_slow → arp_xmit
• KASAN reports indicating "null-ptr-deref in range" during netfilter processing
• Unexpected system reboots coinciding with ARP traffic processing

Detection Strategies

• Monitor kernel logs for "Fatal exception in interrupt" messages associated with netfilter components
• Implement auditd rules to track modifications to arptables and nftables configurations
• Deploy kernel crash dump analysis to identify patterns matching this vulnerability signature
• Use eBPF-based monitoring to track unusual combinations of netfilter extension loading

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) for post-mortem analysis of any kernel panics
• Configure syslog forwarding to capture kernel oops messages in real-time
• Monitor for unusual arptables rule modifications through auditctl
• Implement alerting on repeated kernel panics that may indicate exploitation attempts

How to Mitigate CVE-2026-31424

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the x_tables ARP restriction fix
• Review existing arptables configurations and remove any non-ARP-specific matches or targets
• Restrict CAP_NET_ADMIN capabilities to only essential services and users
• Consider temporarily disabling nft_compat module if arptables functionality is not required

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix restricts arptables to only load NFPROTO_ARP registered extensions, preventing the loading of incompatible NFPROTO_UNSPEC matches and targets. Multiple stable kernel branches have received backported fixes:

• Kernel commit 1cd6313c8644
• Kernel commit 3d5d488f1177
• Kernel commit 3e79374b03bf
• Kernel commit dc3e27dd7d76
• Kernel commit e7e1b6bcb389
• Kernel commit f00ac65c90ea

Workarounds

• Restrict arptables rules to only use native ARP-compatible extensions: arpt_CLASSIFY, arpt_mangle, and arpt_MARK
• Blacklist or unload the nft_compat module if nftables compatibility with legacy xtables extensions is not required
• Use network namespaces to isolate sensitive workloads from potentially vulnerable arptables configurations
• Implement SELinux or AppArmor policies to restrict netfilter rule modification capabilities

# Configuration example
# Restrict arptables to ARP-native extensions only
# List currently loaded xtables modules
lsmod | grep -E "xt_|arpt_"

# Unload nft_compat if not needed
modprobe -r nft_compat

# Blacklist nft_compat to prevent automatic loading
echo "blacklist nft_compat" >> /etc/modprobe.d/nft-compat.conf

# Verify arptables only uses native extensions
arptables -L -v