CVE-2026-43453

What it actually does

This vulnerability is a stack out-of-bounds read in the Linux kernel netfilter nf_tables pipapo set implementation, specifically in nft_set_pipapo pipapo_drop(). During rule removal, the function evaluates rulemap[i + 1].n even on the final iteration, reading 4 bytes past the end of a stack-allocated rulemap array. The value is not ultimately used by pipapo_unmap() on the last iteration, but the out-of-bounds read still occurs at the call site and has been confirmed by KASAN. Because the flaw is in kernel code reachable by a local privileged-enough user that can manipulate nftables rules, impact can include kernel memory disclosure and kernel crash/denial of service. The CVSS vector indicates local attack, low complexity, low privileges, no user interaction, high confidentiality impact, and high availability impact, with no direct integrity impact identified.

Why it matters to the business

Systems that allow local users, containers, or service accounts to create or modify nftables rules may be exposed to kernel instability or potential leakage of sensitive kernel memory. In practical terms, exploitation could disrupt network filtering, crash affected Linux hosts, or expose information useful for further local privilege-escalation research. The vulnerability is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad active exploitation is not currently indicated; however, because it affects the Linux kernel networking/firewall subsystem, outages can have high operational impact on firewalls, gateways, Kubernetes/container hosts, and multi-user Linux servers.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient privileges or namespace capabilities to interact with nf_tables, such as CAP_NET_ADMIN in the relevant network namespace. They then create nftables pipapo sets/rules with conditions that cause pipapo_drop() to process the maximum or relevant field layout during rule deletion or update. When the crafted nftables object is removed, the kernel evaluates rulemap[i + 1].n on the final loop iteration and reads past the stack array boundary. Depending on kernel configuration and surrounding stack contents, this may trigger a KASAN report, kernel warning, panic, or potentially disclose adjacent stack data through a secondary observable behavior. There is no public exploit maturity reported in the supplied data, and the flaw is constrained to local attackers with nftables administration capability rather than unauthenticated remote users.

How to fix it

Update the Linux kernel to a vendor release that contains the upstream fix for netfilter nft_set_pipapo pipapo_drop(), which passes a safe value on the final iteration instead of reading rulemap[i + 1].n. Because no exact fixed package versions were provided, use distribution security advisories from the relevant Linux vendor and install the latest supported kernel/security update for the affected release. Reboot into the fixed kernel and remove old vulnerable kernels where operationally appropriate. As mitigations until patching is complete, restrict local shell access, limit CAP_NET_ADMIN and root-equivalent privileges, avoid granting nftables administration rights inside containers or untrusted namespaces, disable unneeded user namespaces where feasible, and restrict who can modify nftables rules. On systems where nftables is not required, consider disabling or avoiding nf_tables usage, but do not rely on this as a substitute for kernel patching.

How to confirm the fix worked

Confirm the running kernel version with uname -a and compare it to the fixed kernel version documented by the relevant distribution advisory. Verify that the patched kernel is actually running after reboot, not merely installed. Review package manager history to confirm the kernel security update was applied successfully. If possible in a non-production test environment, reproduce the vendor or upstream KASAN test scenario against the old kernel and confirm it no longer triggers on the updated kernel. Also validate that untrusted users and containers do not have CAP_NET_ADMIN or nftables management access unless explicitly required.

Typical attack path

1. Gain local code execution on an affected Linux host through a shell, compromised service account, container escape-adjacent foothold, or legitimate low-privileged account.
2. Obtain or already possess the ability to administer nftables in a network namespace, typically CAP_NET_ADMIN or equivalent root-level firewall management permissions.
3. Create nftables pipapo set/rule structures that exercise the vulnerable nft_set_pipapo rule mapping logic.
4. Trigger rule deletion, replacement, or cleanup so pipapo_drop() is invoked.
5. Cause the kernel to read 4 bytes beyond the stack-allocated rulemap array on the final iteration.
6. Observe a denial-of-service condition, kernel diagnostic output, or potentially use any leaked kernel memory information to support follow-on exploitation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs and crash telemetry for evidence of the vulnerable code path being hit. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore records, KASAN reports, kernel oops/panic logs, auditd records for nft commands, shell history for nftables manipulation, and container/orchestrator audit logs showing CAP_NET_ADMIN or privileged container activity. Look for stack-out-of-bounds reports referencing pipapo_drop, nf_tables, nft_set_pipapo, or KASAN, especially near nftables rule deletion or replacement events. Also investigate unexpected nft command executions, rapid create/delete cycles of nftables sets, or firewall rule changes initiated by unusual users, service accounts, or containers. Absence of logs does not prove absence of exploitation, because a successful crash may truncate logs and non-KASAN production kernels may not emit detailed memory-safety diagnostics.

• BUG: KASAN: stack-out-of-bounds in pipapo_drop
• pipapo_drop+0x
• [nf_tables]
• nft_set_pipapo
• Read of size 4 at addr
• This frame has 1 object:
• 'rulemap'
• exactly 4 bytes past the end of the rulemap array
• kernel: BUG: KASAN: stack-out-of-bounds
• kernel: nf_tables
• kernel: pipapo_drop
• nft delete set
• nft delete rule
• nft add set
• nft -f

What your security team should do

• Prioritize patching internet-facing Linux gateways, firewalls, Kubernetes/container hosts, shared multi-user servers, and systems where untrusted users or containers may have CAP_NET_ADMIN.
• Inventory Linux hosts using nftables/nf_tables and map which workloads or users can administer firewall rules.
• Apply the latest vendor-supported kernel update and reboot systems into the fixed kernel.
• Temporarily restrict CAP_NET_ADMIN, privileged containers, user namespaces, and nftables rule-management access for untrusted users until patching is complete.
• Monitor kernel logs for KASAN, out-of-bounds, nf_tables, nft_set_pipapo, or unexplained kernel crash events.
• Treat unexpected nftables rule creation/deletion by non-administrative services or containers as suspicious and investigate promptly.
• Because EPSS is very low and the CVE is not in KEV, schedule normal but timely remediation rather than emergency internet-wide incident response unless local privilege exposure is high.