CVE-2026-43114

What it actually does

This flaw is in the Linux kernel netfilter nftables pipapo set implementation when AVX2-optimized matching is used. Under specific conditions involving concatenated set keys, such as an IPv4 address plus port, and expired or flushed set entries, the AVX2 lookup path can incorrectly return an element that does not fully match the packet or set operation being evaluated. Technically, stale match bits from a prior field can survive into later matching logic, causing nftables to treat a non-matching entry as if it matched. Depending on how the affected nftables set is used, this can lead to incorrect firewall, filtering, or policy decisions, and can also cause legitimate rule or set reloads to fail with apparent duplicate or clashing elements.

Why it matters to the business

Organizations relying on affected Linux kernels for nftables-based firewalling, traffic filtering, network segmentation, container networking, or appliance-style packet filtering may experience incorrect policy enforcement or failed firewall rule updates. In practical terms, traffic that should be denied could be incorrectly allowed, traffic that should be allowed could be blocked, or automated firewall reloads could fail, reducing availability and trust in network controls. Although the CVSS score is critical, current exploitation signals are low: EPSS is 0.00356, flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported public exploit maturity in the supplied data.

How an attack unfolds

An attacker would need to target a system that uses nftables pipapo sets with AVX2 acceleration and rule logic based on concatenated fields, such as source or destination address combined with port or protocol. The vulnerable condition is most relevant when sets contain entries that expire, are flushed, or are replaced while older-generation entries still influence lookup behavior. The attacker sends network traffic crafted so that the first field of the lookup key matches a stale or expired entry while a later field differs. Because the AVX2 path can stop too early and leave stale bits in the match map, the kernel may return a non-matching element as if it were valid. If that set is used in an allow, deny, rate-limit, redirect, or segmentation rule, the attacker may cause an unintended policy decision. A second operational exploitation pattern is triggering or waiting for set reload conditions that cause nftables to report false clashes, which can disrupt firewall automation or prevent policy updates from being applied.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for `netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry`. No exact fixed package versions were provided in the input, so use the latest kernel security update from the relevant distribution or vendor and confirm that the vendor advisory for CVE-2026-43114 is included. Systems using nftables heavily, especially firewalls, routers, Kubernetes/container hosts, load balancers, and security appliances, should be prioritized. If immediate patching is not possible, reduce exposure by avoiding nftables pipapo sets with concatenated keys and expiring elements where feasible, disabling or replacing affected dynamic set logic, using simpler set structures, or temporarily moving critical enforcement to unaffected controls. Where operationally acceptable, disabling AVX2-optimized matching by using a kernel without that optimization or a vendor-supported mitigation may reduce exposure, but patching is the preferred remediation.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that contains the netfilter pipapo AVX2 fix, not merely that a package is installed on disk. Validate by checking the active kernel version after reboot and comparing it with the vendor advisory or changelog for this vulnerability. On systems using nftables, review rulesets for pipapo-style set usage, concatenated keys, timeouts, intervals, ranges, and frequent flush/reload workflows. After patching, test representative nftables reload operations and dynamic set expiry scenarios to confirm that false duplicate or clashing element errors no longer occur. Also perform functional firewall tests to verify that packets matching only a partial tuple do not trigger unintended allow or deny rules.

Typical attack path

1. Identify an exposed Linux system or network device that relies on nftables for packet filtering or policy enforcement.
2. Infer or probe whether the target uses nftables sets with concatenated keys, such as address-and-port combinations, ranges, timeouts, or dynamically updated sets.
3. Wait for or induce normal set churn, such as element expiry, flush-and-reload operations, or automated firewall policy replacement.
4. Send crafted traffic where an early key field matches a stale or expired entry but later key fields do not match the intended active element.
5. Abuse the incorrect AVX2 lookup result to trigger an unintended nftables rule match or to interfere with firewall rule updates.
6. Use the resulting policy mistake to bypass filtering, reach a protected service, disrupt connectivity, or degrade firewall reliability.

How to detect it

There are no definitive, vulnerability-specific indicators that prove exploitation from logs alone. Detection should focus on three areas: nftables control-plane failures, unexpected firewall behavior, and suspicious traffic that appears to have bypassed expected policy. Review system logs, kernel logs, audit logs, configuration-management logs, and firewall orchestration logs for nftables reload failures, duplicate or clashing element messages, failed set updates, or policy rollback events. Examine nftables rulesets for concatenated-key sets with timeouts, intervals, ranges, or frequent flush/reload operations, as those are the highest-risk configurations. For possible exploitation, compare packet captures, firewall counters, nftables trace output, and service access logs to identify traffic that reached services despite expected nftables deny rules, especially when source address, destination address, port, or protocol only partially matches an allowed set element. If security monitoring records command execution, look for unusual or repeated invocation of `nft` by automation accounts or unexpected users, although exploitation of the lookup flaw itself may not require local command execution. Threat actor-specific detections are not available from the supplied data.

• nft_set_pipapo_avx2
• nft_set_pipapo_avx2_lookup
• nft_pipapo_avx2_lookup_slow
• Error: Could not process rule: File exists
• clashing element
• flush set
• nft -f -
• nft -f

What your security team should do

• Prioritize patching internet-facing Linux firewalls, routers, VPN gateways, container hosts, and network-security appliances that use nftables.
• Inventory Linux systems using nftables sets with concatenated keys, dynamic timeouts, interval/range sets, or automated flush-and-reload rule deployment.
• Monitor vendor advisories and distribution kernel changelogs for the specific backported fix, since fixed versions were not provided in the source data.
• Until patched, avoid high-risk nftables patterns involving expiring concatenated pipapo sets for critical allow/deny decisions where feasible.
• Review firewall automation logs for failed nftables reloads, false duplicate-element errors, or unexpected policy rollback events.
• Perform post-patch validation with packet-level tests for critical firewall rules rather than relying only on package version checks.
• Because this is not currently KEV-listed, has no known ransomware use, and has low flat EPSS, prioritize based on exposure and nftables usage rather than treating all Linux hosts equally.