CVE-2026-43024

What it actually does

This is a local availability vulnerability in the Linux kernel netfilter/nf_tables subsystem. The kernel accepted an immediate NF_QUEUE verdict in nftables rule evaluation even though normal userspace nftables tooling does not use that form, and the ARP family does not support queueing. A local user with the ability to create or modify nftables state, or who can obtain that capability through a network namespace configuration, may be able to trigger an invalid kernel code path and cause a denial of service such as a kernel crash, panic, or network filtering failure. The issue does not provide direct confidentiality or integrity impact, and exploitation requires local access and privileges sufficient to interact with nf_tables.

Why it matters to the business

Successful exploitation can make affected Linux systems unavailable, disrupting workloads, network services, container hosts, firewalls, gateways, or appliances that rely on the Linux kernel packet filtering stack. The CVSS score is moderate, EPSS is currently very low and stable, and there is no known CISA KEV listing or public exploit maturity reported, so this should be prioritized behind remotely exploitable or actively exploited issues but still remediated through normal kernel patch cycles, especially on multi-user systems and container platforms where local users may gain network namespace capabilities.

How an attack unfolds

An attacker first obtains local access to an affected Linux system. They then attempt to gain the ability to program nftables rules, typically through CAP_NET_ADMIN, administrative access, or permissive unprivileged user and network namespace settings. Instead of using the ordinary nftables queue expression path, the attacker crafts an nf_tables rule or netlink message that encodes an immediate NF_QUEUE verdict. When the kernel evaluates the malformed or unsupported rule path, particularly in a family such as ARP where queue support is not available, the vulnerable kernel may hit an unsafe condition. The practical outcome is denial of service: the host may crash, panic, or suffer network filtering instability. The fixed behavior rejects immediate NF_QUEUE verdicts globally before they can reach the unsafe path.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream fix rejecting immediate NF_QUEUE verdicts in nf_tables. Because fixed versions vary by distribution and kernel branch, use the security advisory for the relevant Linux distribution or appliance vendor and install the patched kernel package, then reboot into the updated kernel. As interim mitigation, restrict nftables administration to trusted users only, remove unnecessary CAP_NET_ADMIN grants, review container runtime settings that provide NET_ADMIN, and consider disabling unprivileged user namespaces where operationally feasible. Limit local shell access on shared systems and ensure only trusted automation can modify nftables rulesets.

How to confirm the fix worked

Confirm the running kernel is a vendor-patched build that includes the nf_tables fix for rejecting immediate NF_QUEUE verdicts; package installation alone is insufficient until the host has rebooted into the patched kernel. Validate with the distribution’s package manager and kernel version reporting, and compare against the vendor advisory for the specific kernel branch. Review whether untrusted users or containers can obtain CAP_NET_ADMIN or create user/network namespaces. Where safe and approved, security teams can use a non-production test system to verify that crafted immediate NF_QUEUE verdicts are rejected rather than accepted or causing instability. Also confirm that nftables rulesets continue to load normally after patching.

Typical attack path

1. Gain local shell access on an affected Linux system.
2. Obtain or abuse privileges that allow interaction with nf_tables, such as CAP_NET_ADMIN or a network namespace with nftables access.
3. Craft an nftables netlink request containing an immediate NF_QUEUE verdict rather than a normal userspace nft queue expression.
4. Install or trigger the crafted rule in an affected ruleset or family, including paths where queueing is unsupported.
5. Cause the kernel to enter the vulnerable nf_tables code path, resulting in host or network-stack denial of service.

How to detect it

There are no public, reliable, exploit-specific indicators for this vulnerability, and normal nftables userspace tools do not usually generate the vulnerable immediate NF_QUEUE form. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and audit logs around unexpected reboots, kernel panics, or network-filtering failures. Look for kernel oops or panic messages referencing nf_tables, nftables, netfilter, NF_QUEUE, nft_immediate, nft_queue, or ARP-family rule processing. Review auditd or equivalent telemetry for local users or containers invoking nft, sending NETLINK_NETFILTER messages, or making unusual nftables ruleset changes shortly before a crash. On container hosts, correlate crashes with containers granted CAP_NET_ADMIN or privileged mode. Absence of these artifacts does not prove non-exploitation because a denial-of-service crash may leave limited logs.

• nf_tables
• nftables
• netfilter
• NF_QUEUE
• nft_immediate
• nft_queue
• NETLINK_NETFILTER
• NFT_MSG_NEWRULE
• kernel panic
• Oops:
• BUG:
• CAP_NET_ADMIN
• nft add rule
• family arp

What your security team should do

• Patch affected Linux kernels during the next standard maintenance window, with higher priority for multi-user hosts, container platforms, network appliances, firewalls, and systems that grant CAP_NET_ADMIN to workloads.
• Inventory systems using Linux kernels with nf_tables enabled and identify those where untrusted users, containers, or automation can modify nftables state.
• Reduce exposure by removing unnecessary NET_ADMIN capabilities from containers and service accounts.
• Disable or restrict unprivileged user namespaces where feasible, especially on shared compute systems.
• Monitor for kernel crashes, panics, or oops events involving nf_tables, nftables, netfilter, NF_QUEUE, or ARP-family ruleset activity.
• Ensure incident response teams preserve kernel logs and audit logs after unexplained Linux host crashes, because a reboot may rotate volatile evidence.
• Track vendor advisories for exact fixed kernel package versions because no universal fixed version is provided for all Linux distributions.