Look up another CVE · open CVE-2026-80664 in the interactive tracker
CVE-2026-80664
netfilter: xt_nat: reject unsupported target families
Published 2026-08-28 (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-80664 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
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update 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
xt_nat SNAT and DNAT target handlers assume IP-family conntrack state is present and can dereference a NULL pointer when instantiated from an unsupported family through nft_compat. A bridge-family compat rule can therefore trigger a NULL-dereference in nf_nat_setup_info(). Reject non-IP families in xt_nat_checkentry() so unsupported targets cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT compat users and leave the runtime fast path unchanged. [ The crash was fixed via 9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"), so this patch is no longer critical. Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra family check is a good idea in any case. ]
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/xt_nat.c
- What this is
- NETFILTERMAINTAINERS section matched on net/netfilter/ · netfilter-devel@vger.kernel.org · Maintained
- Kernel module
- xt_nat
Check it on the machine
grep -wE 'CONFIG_NETFILTER|CONFIG_NETFILTER_XT_NAT' /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 xt_natPrints 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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixiem
- forky, sidMnot built on amd64/rt-amd64, arm64/rt-arm64
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_NETFILTER, CONFIG_NETFILTER_XT_NAT
- 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-28 (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.13%, higher than 2.2% 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
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.7 | 5.10.261 | 49abe5643914 |
| 3.7 | 5.15.212 | 0afc9ad987c0 |
| 3.7 | 6.1.178 | 4fbc2bac02ed |
| 3.7 | 6.6.145 | a842dab87cab |
| 3.7 | 6.12.97 | e35c048d7511 |
| 3.7 | 6.18.40 | 679ced28a9dc |
| 3.7 | 7.1.5 | ec88fa71c820 |
| 3.7 | 7.2 | 5d1a2240935e |
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
- Exploitation requires installing a bridge-family nft_compat SNAT/DNAT rule via NETLINK_NETFILTER (nftables netlink), a local syscall path; although matching bridge traffic can trigger evaluation, the vulnerable rule state cannot be created without local netfilter administration.
- AC:LAttack complexity, low
- Once CAP_NET_ADMIN is held in the target network namespace, xt_request_find_target() deterministically resolves UNSPEC-family SNAT/DNAT rev 1/2 targets for bridge chains, and sending bridge traffic through the committed rule reliably reaches nf_nat_setup_info() with a NULL nf_conn from nf_ct_get().
- PR:LPrivileges required, low
- All nfnetlink handlers are gated by netlink_net_capable(skb, CAP_NET_ADMIN), which checks capability in the socket network namespace user namespace; unprivileged local users routinely obtain CAP_NET_ADMIN via user and network namespaces (unshare -Urn), enabling installation of the malicious bridge compat rule.
- UI:NUser interaction, none
- No victim interaction is required beyond the attacker obtaining namespace-local CAP_NET_ADMIN, creating a bridge nftables chain with a compat SNAT/DNAT target, and delivering matching bridge traffic; no third-party actions such as mounting filesystems or opening files are needed.
- S:UScope, unchanged
- Impact is confined to the host kernel netfilter/NAT subsystem within the same security authority; this is not a VM escape, hypervisor boundary crossing, or IOMMU/DMA sandbox bypass, but standard in-kernel misbehavior from an invalid family/target pairing.
- C:LConfidentiality impact, low
- The primary runtime failure is a NULL nf_conn dereference in nf_nat_setup_info(), and the surrounding nft_compat bridge/xtables semantic mismatch can leak limited kernel information via oops register dumps and crash logs readable by the local attacker who triggered the fault.
- I:HIntegrity impact, high
- Missing family validation lets IP-family NAT targets execute under bridge nft_compat semantics where nf_ct_get() yields NULL, constituting a type/family confusion that can corrupt netfilter verdict and NAT handling before faulting; mis-instantiated SNAT/DNAT targets should not run in bridge context at all.
- A:HAvailability impact, high
- Passing bridge traffic through a bridge-family compat SNAT/DNAT rule causes nf_nat_setup_info() to dereference the NULL connection from nf_ct_get(), producing a kernel oops or panic; repeated matching traffic can retrigger the crash for sustained denial of service.