CVE-2026-98484: netfilter: nf_tables: skip expired catchall elements on insert and delete
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: skip expired catchall elements on insert and delete
nftsetelemcatchallinsert() looks up duplicates with nftsetelemactive() only, while nftsetcatchalllookup() and the dump path additionally skip expired elements.
Once a catchall element with a timeout expires, this predicate drift makes it invisible to userspace dumps, yet it still blocks re-insertion: with NLMFEXCL the request fails with -EEXIST, and without it the request reports success but silently inserts nothing. The stale entry only goes away when the (user-tunable) gc interval elapses, so the catchall rule may silently stop matching for an arbitrarily long time after its first expiration.
The delete path shows the same drift: nftsetelemcatchalldeactivate() picks the first active-next entry in the catchall list, so with an expired entry still pending GC it retires the stale entry instead of the fresh one, and it deactivates an element that userspace no longer sees instead of failing with -ENOENT.
Align both walks with the lookup and dump predicates: only an element that is active and not expired counts as a duplicate or delete candidate, using the per-netns timestamp taken at transaction start, in line with the set backend .insert/.deactivate and catchall GC sync paths.
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.9-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 5.15.224 - 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.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.55 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.9 - 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 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this behavior?
Systems using nftables catchall set elements with timeouts are affected when an element expires but remains pending garbage collection. The issue depends on expired catchall entries, not merely on having nftables enabled.
What would an operator observe if a stale expired element is present?
The expired element can be absent from userspace dumps while still preventing a replacement from being inserted. An insertion with NLM_F_EXCL fails with -EEXIST; without that flag, it can report success while inserting nothing, leaving the catchall rule unable to match.
Can deletion behave unexpectedly as well?
Yes. While an expired entry is pending garbage collection, deletion can deactivate the stale, invisible entry rather than a fresh entry, instead of returning -ENOENT when userspace cannot see a matching element.
What can be done if the corrected kernel is not yet available?
The stale entry is removed when the configured garbage-collection interval elapses. Because that interval is user-tunable, the duration of the incorrect behavior depends on the configured GC interval.