CVE-2026-80664: netfilter: xt_nat: reject unsupported target families
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtnat: reject unsupported target families
xtnat 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 nftcompat. A bridge-family compat rule can therefore trigger a NULL-dereference in nfnatsetupinfo().
Reject non-IP families in xtnatcheckentry() so unsupported targets cannot be installed. Keep NFPROTOINET allowed for valid inet NAT compat users and leave the runtime fast path unchanged.
[ The crash was fixed via 9dbba7e694ec ("netfilter: nftcompat: 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. ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 9dbba7e694ec - Compensating control
If you are using nft/ebtables bridge-family compatibility, ensure only supported IP families (IPv4/IPv6) are allowed; reject/deny non-IP/unsupported target families so they cannot be instantiated through nft_compat into xt_nat/NAT handlers.
Event History
Frequently Asked Questions
Which systems are exposed to the NULL dereference?
Exposure requires xt_nat SNAT or DNAT targets to be instantiated from an unsupported protocol family through nft_compat. The described case is a bridge-family compatibility rule; NAT targets are relevant only to IPv4 and IPv6 families.
What access or condition is needed to trigger the crash?
A bridge-family nft_compat rule must be able to install an unsupported xt_nat target. When that target is used, the handler can assume IP-family conntrack state exists and dereference a NULL pointer in nf_nat_setup_info().
Is this still considered critical if the newer family validation is not present?
The description states that the crash was already fixed by commit 9dbba7e694ec, which made nft_compat ebtables emulation reject non-bridge targets. The additional xt_nat family check is described as defense in depth and no longer critical after that earlier fix.
How can I identify a potentially affected configuration?
Review nft_compat and ebtables-emulation rules for bridge-family rules that use xt_nat SNAT or DNAT compatibility targets. Such non-IP-family NAT target use is the configuration the new check rejects.