CVE-2026-43451

What it actually does

This is a local denial-of-service flaw in the Linux kernel netfilter nfnetlink_queue bridge verdict handling path. When a queued PF_BRIDGE packet is dequeued and a userspace verdict message includes malformed VLAN attributes, the kernel can return from the error path without freeing the nf_queue_entry, its associated sk_buff, and held references such as network device and network namespace references. Repeating the operation leaks kernel memory and references until the system experiences memory pressure, degraded networking, or a kernel out-of-memory condition.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, disrupting workloads, network services, containers, virtualized environments, or appliances that rely on Linux bridge filtering and NFQUEUE processing. The risk is primarily availability-focused and requires local access or equivalent ability to interact with the relevant netfilter queue functionality, but systems hosting untrusted local users, containers, or delegated network administration capabilities are more exposed. This issue is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so it should be prioritized based on exposure to local users and kernel update cadence rather than evidence of broad exploitation.

How an attack unfolds

An attacker first obtains local access with sufficient privileges or namespace capabilities to influence nfnetlink_queue verdict handling for bridged traffic. They configure or use an existing netfilter NFQUEUE path for PF_BRIDGE packets, cause packets to be queued to userspace, and then send crafted verdict messages containing inconsistent VLAN attributes, such as including NFQA_VLAN without the required NFQA_VLAN_TCI. The kernel removes the queue entry from internal data structures, attempts to parse the malformed bridge VLAN attributes, hits the error path, and returns without releasing the dequeued packet entry and associated references. By repeating this cycle, the attacker steadily consumes kernel memory and reference-counted resources until the host becomes degraded, kills processes, loses network functionality, or requires reboot.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fix for the nfnetlink_queue bridge verdict error path. Because exact fixed package versions vary by distribution and no specific fixed versions were provided, use vendor advisories for the relevant distribution, appliance, container host, hypervisor host, or embedded kernel build and deploy the vendor-patched kernel. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and network namespace creation, disabling or removing unneeded NFQUEUE bridge rules, limiting untrusted container privileges, and monitoring systems that use Linux bridges with netfilter queueing.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is at a vendor-fixed version using commands such as uname -a and the distribution package manager. Review vendor changelogs or kernel source patches for the netfilter/nfnetlink_queue fix that reinjects or drops the entry on the nfqa_parse_bridge() error path. Validate that workloads no longer rely on an older booted kernel after patching by checking bootloader entries and reboot status. For exposure validation, inventory systems using Linux bridge filtering, NFQUEUE rules, or userspace queue handlers by reviewing nftables/iptables bridge-family rules and nfqueue-related services. In test environments only, a controlled regression test can confirm that malformed bridge verdict VLAN attributes no longer cause persistent kernel memory growth.

Typical attack path

1. Gain local access to an affected Linux system or a context with sufficient network namespace/netfilter privileges.
2. Identify or create a bridge/netfilter path that sends PF_BRIDGE packets to an NFQUEUE userspace handler.
3. Generate bridged packets so entries are queued for userspace verdict processing.
4. Send crafted nfnetlink_queue verdict messages with malformed VLAN attributes, such as NFQA_VLAN present while NFQA_VLAN_TCI is absent.
5. Trigger the vulnerable bridge verdict error path repeatedly so nf_queue_entry and sk_buff objects are leaked.
6. Continue until kernel memory is exhausted, network resources become pinned, or the system experiences denial of service.

How to detect it

There is no reliable single log entry that proves exploitation because the flaw is a kernel memory/reference leak rather than an authentication event or crash with a unique signature. Investigate systems for suspicious correlation between NFQUEUE or bridge netfilter activity and rising unreclaimable kernel memory, sk_buff/slab growth, network namespace or network device reference retention, OOM killer events, or unexplained host/network instability. Useful sources include kernel logs, system journal, audit logs for CAP_NET_ADMIN or namespace activity, nftables/iptables configuration history, process accounting for NFQUEUE userspace handlers, eBPF/kernel telemetry if available, and memory/slab statistics such as /proc/meminfo, /proc/slabinfo, and slabtop output. Look for local users or containers creating bridge/NFQUEUE rules, opening nfnetlink sockets, or running custom queue-verdict tooling shortly before memory exhaustion. If kernel tracing, crash dumps, or debug logs are available, search for symbols associated with the vulnerable path, especially nfqnl_recv_verdict and nfqa_parse_bridge, but absence of these strings does not rule out exploitation.

• nfnetlink_queue
• NFQUEUE
• NFQA_VLAN
• NFQA_VLAN_TCI
• nfqnl_recv_verdict
• nfqa_parse_bridge
• Out of memory: Killed process
• oom-killer
• page allocation failure
• /proc/slabinfo
• /proc/net/netfilter/nfnetlink_queue

What your security team should do

• Prioritize patching Linux hosts that allow untrusted local users, run privileged or semi-privileged containers, expose user-controlled network namespaces, or use Linux bridges with NFQUEUE-based packet inspection.
• Inventory affected systems by kernel version and by use of bridge netfilter/NFQUEUE functionality; treat container hosts, network appliances, firewalls, IDS/IPS sensors, and virtualization hosts as higher priority.
• Deploy vendor-patched kernels and reboot systems into the fixed kernel; verify the active kernel version after reboot.
• Temporarily remove unnecessary NFQUEUE rules for bridged traffic and restrict CAP_NET_ADMIN, privileged containers, and untrusted namespace creation until patching is complete.
• Monitor for unexplained kernel memory growth, OOM killer events, network device reference leaks, and repeated netfilter queue activity on systems that cannot be patched immediately.
• Because there is no KEV listing, no known ransomware use, no known exploit maturity, and low EPSS, handle this as a targeted local availability risk rather than an internet-scale emergency unless local multi-tenant exposure exists.