REDHAT-BUG-2466994: High severity Linux Kernel vulnerability

Published May 6, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftsetpipapoavx2: don't return non-matching entry on expiry

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo.

This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

We successfully re-inserted a . b c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching element only considering the first field,

i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nftpipapoavx2lookupslow' fallback.

Bisection points to 7711f4bb4b36 ("netfilter: nftsetpipapo: fix range overlap detection") but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.

Affected Software

1 affected component
Linux Kernel

Event History

May 6, 2026
Data Sourced
via Red Hat·10:02 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Which systems are exposed to this issue?

Systems using Linux kernel netfilter nftables pipapo sets with the AVX2 matching implementation are affected. The described failure involves pipapo sets with composite keys such as IPv4 address plus port.

2

What operation triggers the erroneous behavior?

The issue occurs when a pipapo set is flushed and then reloaded with entries, causing prior-generation entries to be skipped during AVX2 lookup. A later insertion can be incorrectly reported as clashing with a different reinserted entry that shares only the first key field.

3

Are non-AVX2 implementations affected?

The generic C implementation is not reported to show this error. The issue also does not occur when lookup uses the nft_pipapo_avx2_lookup_slow fallback for the final field.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203