CVE-2026-72416

CVE-2026-72416 exposes a semantic boundary failure in how Linux netfilter handles verdict translation between ebtables and nftables. The vulnerability exists in the nft_compat layer, which bridges legacy ebtables target extensions to nftables infrastructure. When an ebtables target returns a bridge-specific verdict (EBT_ACCEPT, EBT_DROP), the nft_compat layer lacks the validation that was added to ebtables proper in commit 11ff7288beb2. Instead of rejecting the incompatible verdict, it falls back to NFPROTO_UNSPEC — a semantic void that creates undefined behavior in the packet filtering pipeline. This is not a theoretical edge case. The NFPROTO_UNSPEC fallback means the firewall loses its semantic anchor: packets are not definitively accepted or dropped. In a stateful firewall context, a packet that fails verdict translation may be tracked as part of an established connection, causing subsequent packets in that flow to bypass rule evaluation entirely. One malformed verdict translation could neutralize dozens of downstream rule evaluations — a flow-level bypass, not merely a packet-level one. The practical attack surface requires specific conditions: a system running nftables with rules that invoke ebtables-compatible extensions (such as meta nfproto bridge or other ebtables-specific targets), and the attacker controlling or knowing the rule construction sequence. This is not opportunistic scanning fodder. However, the narrowness of the exploit path does not indicate limited impact — it indicates specialized knowledge requirements, which the EPSS model captures as low probability but cannot measure against the severity of enforcement failure when triggered. The deeper issue is architectural. The netfilter subsystem now maintains three verdict semantics (NF_*, EBT_*, and nftables native), and each compatibility layer is a seam where semantic assumptions break. The nft_compat layer was created to ease the ebtables-to-nftables transition, but it creates ongoing maintenance burden: every time ebtables validation tightens, nft_compat must be treated as a dependent component. The fix for ebtables proper was correct but incomplete — it didn't propagate to the compatibility layer that translates its semantics. For defenders: identify whether any nftables rulesets invoke ebtables-compatible extensions. If they do, audit the rule construction for bridge-specific targets and verify that verdict translation is functioning as expected. Monitor for unexpected traffic flows that bypass intended filtering. The long-term remediation is shrinking the compatibility surface, but that creates adoption pressure — the same tension that allowed this vulnerability to persist. The temporal question is equally important: how many other 'missed' patches exist in nft_compat right now, awaiting rediscovery?

Reviewed through automated stages and approved by a human before publication.