FlawAtlas
Search the atlas
CVE-2026-23111 Not scored

netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.

Exploit probability 0.3%
Published February 13, 2026
Required by Not available
Last source change July 16, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

1748 explicit affected versions

03 / CONNECTIONS

Connected vulnerabilities

related ALSA-2026:6570
related OPENSUSE-SU-2026:20416-1
related SUSE-SU-2026:0962-1
related SUSE-SU-2026:1041-1
related SUSE-SU-2026:1081-1
related SUSE-SU-2026:1180-1
related SUSE-SU-2026:1185-1
related SUSE-SU-2026:1187-1
related SUSE-SU-2026:1188-1
related SUSE-SU-2026:1189-1
related SUSE-SU-2026:1225-1
related SUSE-SU-2026:1236-1
related SUSE-SU-2026:1239-1
related SUSE-SU-2026:1244-1
related SUSE-SU-2026:1259-1
related SUSE-SU-2026:1261-1
related SUSE-SU-2026:1262-1
related SUSE-SU-2026:1266-1
related SUSE-SU-2026:1271-1
related SUSE-SU-2026:1272-1
related SUSE-SU-2026:1274-1
related SUSE-SU-2026:1278-1
related SUSE-SU-2026:1279-1
related SUSE-SU-2026:1283-1
related SUSE-SU-2026:1284-1
related SUSE-SU-2026:20667-1
related SUSE-SU-2026:20720-1
related SUSE-SU-2026:20838-1
related SUSE-SU-2026:20845-1
related SUSE-SU-2026:20876-1
related SUSE-SU-2026:20931-1
related SUSE-SU-2026:21004-1
related SUSE-SU-2026:21005-1
related SUSE-SU-2026:21006-1
related SUSE-SU-2026:21007-1
related SUSE-SU-2026:21008-1
related SUSE-SU-2026:21009-1
related SUSE-SU-2026:21020-1
related SUSE-SU-2026:21040-1
related SUSE-SU-2026:21041-1
related SUSE-SU-2026:21042-1
related SUSE-SU-2026:21043-1
related SUSE-SU-2026:21044-1
related SUSE-SU-2026:21045-1
related SUSE-SU-2026:21046-1
related SUSE-SU-2026:21047-1
related SUSE-SU-2026:21048-1
related SUSE-SU-2026:21049-1
related SUSE-SU-2026:21050-1
related SUSE-SU-2026:21051-1
related SUSE-SU-2026:21052-1
related SUSE-SU-2026:21053-1
related SUSE-SU-2026:21054-1
related SUSE-SU-2026:21055-1
related SUSE-SU-2026:21056-1
related SUSE-SU-2026:21057-1
related SUSE-SU-2026:21058-1
related SUSE-SU-2026:21059-1
related SUSE-SU-2026:21060-1
related SUSE-SU-2026:21061-1
related SUSE-SU-2026:21070-1
related SUSE-SU-2026:21071-1
related SUSE-SU-2026:21072-1
related SUSE-SU-2026:21073-1
related SUSE-SU-2026:21074-1
related SUSE-SU-2026:21075-1
related SUSE-SU-2026:21076-1
related SUSE-SU-2026:21077-1
related SUSE-SU-2026:21078-1
related SUSE-SU-2026:21079-1
related SUSE-SU-2026:21080-1
related SUSE-SU-2026:21081-1
related SUSE-SU-2026:21082-1
related SUSE-SU-2026:21083-1
related SUSE-SU-2026:21084-1
related SUSE-SU-2026:21085-1
related SUSE-SU-2026:21086-1
related SUSE-SU-2026:21087-1
related SUSE-SU-2026:21088-1
related SUSE-SU-2026:21089-1
related SUSE-SU-2026:21090-1
related SUSE-SU-2026:21091-1
related SUSE-SU-2026:21096-1
related SUSE-SU-2026:21098-1
related SUSE-SU-2026:21099-1
related SUSE-SU-2026:21100-1
related SUSE-SU-2026:21102-1
related SUSE-SU-2026:21216-1
related SUSE-SU-2026:21217-1
related SUSE-SU-2026:21218-1
related SUSE-SU-2026:21219-1
related SUSE-SU-2026:21220-1
related SUSE-SU-2026:21221-1
related SUSE-SU-2026:21284-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2026-23111

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones.

View original source

05 / REFERENCES

Further evidence