CVE-2026-31424

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xtables: restrict xtcheckmatch/xtchecktarget extensions for NFPROTOARP

Weiming Shi says:

xtmatch and xttarget structs registered with NFPROTOUNSPEC can be loaded by any protocol family through nftcompat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NFINET* constants. This is only correct for families whose hook layout matches NFINET*: IPv4, IPv6, INET, and bridge all share the same five hooks (PREROUTING ... POSTROUTING).

ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NFARPOUT == 1 == NFINETLOCALIN, 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; xtdevgroup 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:devgroupmt+0xff/0x350 Call Trace: <TASK> nftmatcheval (net/netfilter/nftcompat.c:407) nftdochain (net/netfilter/nftablescore.c:285) nftdochainarp (net/netfilter/nftchainfilter.c:61) nfhookslow (net/netfilter/core.c:623) arpxmit (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.