CVE-2026-98793: netfilter: bpf: reject invalid NAT manipulation types
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bpf: reject invalid NAT manipulation types
As bpfctsetnatinfo() is not validating the NAT manipulation type a wrong value can be passed directly to nfnatsetupinfo(). This triggers the WARNON() at nfnatsetupinfo() and if paniconwarn isn't set, then IPSSRCNATDONE is set without adding natbysource and conntrack cleanup tries to unlink an uninitialized hlist node.
Fix this by checking that NAT manipulation type is correct before calling nfnatsetupinfo(). In addition, if the WARNON is hit, return NFDROP instead of continuing with the processing to avoid similar situations in the future.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1
Event History
Frequently Asked Questions
What must an attacker be able to do to trigger the issue?
They must be able to pass an invalid NAT manipulation type through bpf_ct_set_nat_info() so that it reaches nf_nat_setup_info(). The provided information does not specify the privileges or BPF program-loading capabilities required to do this.
What is the impact if the invalid manipulation type reaches the NAT setup path?
It triggers a WARN_ON() in nf_nat_setup_info(). If panic_on_warn is not enabled, the code can mark source NAT as complete without adding the connection to nat_bysource, and later conntrack cleanup can attempt to unlink an uninitialized hlist node.
What mitigation is described when the warning condition is encountered?
The fix validates the NAT manipulation type before calling nf_nat_setup_info(). It also returns NF_DROP when the WARN_ON condition is hit rather than continuing packet processing.