data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-72416 in the interactive tracker

CVE-2026-72416

netfilter: nft_compat: ebtables emulation must reject non-bridge targets

7.3 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/netfilter. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-72416 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormvulnerable6.1.190-1No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixiefixed6.12.100-1Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so on. ebtables targets return incompatible verdicts: EBT_ACCEPT, EBT_DROP, ... We cannot allow fallback to NFPROTO_UNSPEC. ebtables doesn't permit this since 11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets") but that commit missed the nft_compat layer.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/netfilter/nft_compat.c

What this is
NETFILTERMAINTAINERS section matched on net/netfilter/ · netfilter-devel@vger.kernel.org · Maintained
Kernel module
nft_compat

Check it on the machine

grep -wE 'CONFIG_NETFILTER|CONFIG_NFT_COMPAT' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w nft_compat

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

  • bookworm, trixie, forky, sidm
m
a loadable module on every flavour - check lsmod, can be blacklisted
Build switches
CONFIG_NETFILTER, CONFIG_NFT_COMPAT
Reads as
all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-08-15 (2 months ago)source
CVSS
7.3 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.17%, higher than 6.3% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
net/netfilter

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
3.136.6.145efc17b9240d8
3.136.12.97b3f7a84540a0
3.136.18.4033e1875d6b5b
3.137.1.5c129b0185e70
3.137.29dbba7e694ec

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The bug is reached by installing a bridge-family nft_compat rule through NETLINK_NETFILTER (nftables netlink), which is a local syscall path; packet evaluation on bridge hooks can be driven by traffic, but creating the vulnerable rule state requires local netfilter administration.
AC:LAttack complexity, low
Exploitation is deterministic once CAP_NET_ADMIN is held in the target network namespace: xt_request_find_target() falls back to NFPROTO_UNSPEC targets, nft_target_eval_bridge() misinterprets xtables verdicts, and sending matching bridge traffic reliably triggers the faulty evaluation (e.g. NULL ct in nf_nat_setup_info()).
PR:LPrivileges required, low
All nfnetlink entry points are gated by netlink_net_capable(..., CAP_NET_ADMIN), which checks the socket network namespace user namespace; unprivileged local users routinely obtain this capability via user+network namespaces (unshare -Urn), matching the reporters' nft_compat reproduction model.
UI:NUser interaction, none
No victim interaction is required beyond the attacker obtaining namespace-local CAP_NET_ADMIN and installing the malicious bridge nft_compat rule; subsequent packet delivery to the bridge hook is automatic once the rule is committed.
S:UScope, unchanged
Impact is confined to the host kernel and its network filtering state; this is not a VM escape, hypervisor boundary crossing, or IOMMU/DMA sandbox bypass, but standard in-kernel netfilter misbehavior within the same security authority.
C:LConfidentiality impact, low
The primary primitive is verdict-namespace type confusion between xtables (NF_*) and ebtables (EBT_*) return conventions; while no arbitrary read is demonstrated, a triggered kernel oops from NULL ct dereference in nf_nat_setup_info() can expose kernel pointers in crash logs accessible to the local attacker.
I:HIntegrity impact, high
Incompatible verdict translation lets xtables targets run under ebtables semantics: XT_CONTINUE (0xFFFFFFFF/-1) is mapped to EBT_ACCEPT/NF_ACCEPT instead of continuing rule evaluation, and mis-instantiated targets such as SNAT/DNAT can alter connection-tracking/NAT state before faulting, constituting type-confusion integrity impact.
A:HAvailability impact, high
Installing an IP-family UNSPEC target (e.g. SNAT/DNAT rev 1/2) in a bridge nft_compat chain and passing traffic causes nf_nat_setup_info() to dereference a NULL nf_conn from nf_ct_get(), producing a kernel oops/panic; repeated bridge traffic can retrigger the crash for sustained denial of service.