PT-2026-32350 · Linux · Linux
Published
2026-04-13
·
Updated
2026-04-13
·
CVE-2026-31424
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
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)
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux