CVE-2026-43114

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo_avx2: don&amp;#39;t return non-matching entry on expiry<br /> <br /> New test case fails unexpectedly when avx2 matching functions are used.<br /> <br /> The test first loads a ranomly generated pipapo set<br /> with &amp;#39;ipv4 . port&amp;#39; key, i.e. nft -f foo.<br /> <br /> This works. Then, it reloads the set after a flush:<br /> (echo flush set t s; cat foo) | nft -f -<br /> <br /> This is expected to work, because its the same set after all and it was<br /> already loaded once.<br /> <br /> But with avx2, this fails: nft reports a clashing element.<br /> <br /> The reported clash is of following form:<br /> <br /> We successfully re-inserted<br /> a . b<br /> c . d<br /> <br /> Then we try to insert a . d<br /> <br /> avx2 finds the already existing a . d, which (due to &amp;#39;flush set&amp;#39;) is marked<br /> as invalid in the new generation. It skips the element and moves to next.<br /> <br /> Due to incorrect masking, the skip-step finds the next matching<br /> element *only considering the first field*,<br /> <br /> i.e. we return the already reinserted "a . b", even though the<br /> last field is different and the entry should not have been matched.<br /> <br /> No such error is reported for the generic c implementation (no avx2) or when<br /> the last field has to use the &amp;#39;nft_pipapo_avx2_lookup_slow&amp;#39; fallback.<br /> <br /> Bisection points to<br /> 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection")<br /> but that fix merely uncovers this bug.<br /> <br /> Before this commit, the wrong element is returned, but erronously<br /> reported as a full, identical duplicate.<br /> <br /> The root-cause is too early return in the avx2 match functions.<br /> When we process the last field, we should continue to process data<br /> until the entire input size has been consumed to make sure no stale<br /> bits remain in the map.