CVE-2026-31424

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP<br /> <br /> Weiming Shi says:<br /> <br /> xt_match and xt_target structs registered with NFPROTO_UNSPEC can be<br /> loaded by any protocol family through nft_compat. When such a<br /> match/target sets .hooks to restrict which hooks it may run on, the<br /> bitmask uses NF_INET_* constants. This is only correct for families<br /> whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge<br /> all share the same five hooks (PRE_ROUTING ... POST_ROUTING).<br /> <br /> ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different<br /> semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks<br /> validation silently passes for the wrong reasons, allowing matches to<br /> run on ARP chains where the hook assumptions (e.g. state-&gt;in being<br /> set on input hooks) do not hold. This leads to NULL pointer<br /> dereferences; xt_devgroup is one concrete example:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]<br /> RIP: 0010:devgroup_mt+0xff/0x350<br /> Call Trace:<br /> <br /> nft_match_eval (net/netfilter/nft_compat.c:407)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)<br /> nf_hook_slow (net/netfilter/core.c:623)<br /> arp_xmit (net/ipv4/arp.c:666)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix it by restricting arptables to NFPROTO_ARP extensions only.<br /> Note that arptables-legacy only supports:<br /> <br /> - arpt_CLASSIFY<br /> - arpt_mangle<br /> - arpt_MARK<br /> <br /> that provide explicit NFPROTO_ARP match/target declarations.