CVE-2026-31424
Analyzed Analyzed - Analysis Complete
Null Pointer Dereference in Linux netfilter ARP Extension Handling

Publication date: 2026-04-13

Last updated on: 2026-05-20

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-13
Last Modified
2026-05-20
Generated
2026-06-16
AI Q&A
2026-04-13
EPSS Evaluated
2026-06-15
NVD
CVE-2026-31424
EUVD
EUVD-2026-21948
Affected Vendors & Products
Showing 13 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 5.11 (inc) to 5.15.203 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.22 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.168 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.12 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.81 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.134 (exc)
linux linux_kernel From 2.6.39 (inc) to 5.10.253 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's netfilter subsystem, specifically in the x_tables component. It involves the improper handling of xt_match and xt_target structures registered with NFPROTO_UNSPEC, which can be loaded by any protocol family through nft_compat.

The issue arises because these matches/targets use a bitmask based on NF_INET_* constants to restrict which hooks they may run on. This bitmask is only correct for protocol families like IPv4, IPv6, INET, and bridge, which share the same five hooks.

However, ARP has a different hook layout with only three hooks and different semantics. Due to overlapping constant values, the hooks validation incorrectly passes, allowing matches to run on ARP chains where assumptions about hook context do not hold. This can lead to NULL pointer dereferences and kernel crashes.

The fix restricts arptables to only allow NFPROTO_ARP extensions, preventing this mismatch and the resulting faults.

Impact Analysis

This vulnerability can cause kernel crashes due to NULL pointer dereferences when certain netfilter matches or targets are incorrectly applied to ARP protocol chains.

Such crashes can lead to system instability, denial of service, or unexpected reboots, impacting the availability and reliability of affected Linux systems.

Mitigation Strategies

To mitigate this vulnerability, restrict arptables to NFPROTO_ARP extensions only.

Note that arptables-legacy only supports the following explicit NFPROTO_ARP match/target declarations:

  • arpt_CLASSIFY
  • arpt_mangle
  • arpt_MARK
Detection Guidance

This vulnerability manifests as a kernel panic or NULL pointer dereference related to netfilter's handling of ARP protocol hooks. Detection involves monitoring system logs for kernel oops or panic messages indicating null pointer dereferences in netfilter or arp_xmit functions.

You can check your kernel logs for messages similar to the following, which indicate the vulnerability being triggered:

  • Oops: general protection fault, probably for non-canonical address ...
  • KASAN: null-ptr-deref in range ...
  • RIP: devgroup_mt+0xff/0x350
  • Kernel panic - not syncing: Fatal exception in interrupt

To proactively detect if your system is vulnerable, you can verify if arptables extensions are restricted to NFPROTO_ARP only, as the fix involves restricting arptables to NFPROTO_ARP extensions. Checking the loaded netfilter modules and their protocol families may help.

Suggested commands to help detect or investigate the issue include:

  • dmesg | grep -i 'null-ptr-deref\|oops\|panic' # Check kernel logs for relevant errors
  • lsmod | grep xt_ # List loaded netfilter extensions
  • arptables -L # List arptables rules to check for usage of extensions
  • cat /proc/net/netfilter/nf_tables # Inspect nf_tables state if available
Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-31424. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart