CVE-2026-31424
Null Pointer Dereference in Linux netfilter ARP Extension Handling
Publication date: 2026-04-13
Last updated on: 2026-04-18
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux_kernel | linux_kernel | to 416baaa9-dc9f-4396-8d5f-8c081fb06d67 (exc) |
| linux_kernel | linux_kernel | to arptables-legacy (exc) |
| linux | linux_kernel | * |
| linux | arptables | * |
| netfilter | arptables | * |
| linux | linux_kernel | to 416baaa9-dc9f-4396-8d5f-8c081fb06d67 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
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.
How can this vulnerability impact me? :
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.
What immediate steps should I take to mitigate this vulnerability?
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
How can this vulnerability be detected on my network or system? Can you suggest some commands?
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