CVE-2026-43084

What it actually does

This is a Linux kernel use-after-free vulnerability in the netfilter nfnetlink_queue component. The flaw stems from sharing a global hash table across NFQUEUE instances: while one CPU frees an nf_queue_entry, another CPU can still encounter the stale entry while walking the shared list during verdict processing. A local attacker with sufficient privileges to interact with netfilter queue functionality may be able to trigger kernel memory corruption. Practical outcomes can include a kernel crash, denial of service, information disclosure, or potentially local privilege escalation through kernel-code execution, depending on exploit reliability and platform hardening.

Why it matters to the business

Successful exploitation could allow a local attacker to crash affected Linux systems or gain elevated privileges, disrupting workloads and potentially compromising sensitive data. The risk is highest on systems that use netfilter NFQUEUE features, host untrusted local users, run containers or workloads with elevated networking privileges, or expose administrative shell access to many operators. This issue is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, but the high CVSS impact means affected kernels should still be patched through normal vulnerability management timelines.

How an attack unfolds

An attacker first needs local access and the ability to exercise netfilter queue functionality, typically by interacting with NFQUEUE verdict handling through the nfnetlink_queue path. The attacker then creates race conditions across queues so that one execution path frees an nf_queue_entry while another CPU continues to traverse or reference it through the shared hash table. If the race is won, the kernel dereferences freed slab memory in nfqnl_recv_verdict. A basic exploit may simply trigger a kernel oops or panic, causing denial of service. A more advanced exploit would attempt to reclaim the freed slab object with attacker-controlled data and convert the stale reference into controlled kernel memory corruption, potentially escalating privileges. No named threat actor exploitation or ransomware use is currently reported for this CVE.

How to fix it

Upgrade to a Linux kernel build from the operating system or appliance vendor that includes the upstream fix for netfilter: nfnetlink_queue: make hash table per queue. No exact fixed version was provided in the input, so use vendor advisories, distribution security trackers, or kernel package changelogs to identify the corrected build for each supported branch. Reboot into the patched kernel after installation; installing the package alone is not sufficient if the running kernel remains old. If immediate patching is not possible, reduce exposure by removing or disabling nftables/iptables NFQUEUE rules where not required, unloading or blacklisting the nfnetlink_queue module if it is modular and unused, restricting local shell access, limiting CAP_NET_ADMIN and equivalent network-administration privileges, and preventing untrusted workloads from manipulating netfilter queue configuration.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is fixed. Check the active kernel with uname -r and compare it to the vendor-fixed kernel version or advisory. Review kernel package changelogs for the patch text netfilter: nfnetlink_queue: make hash table per queue or references to this CVE. Verify whether nfnetlink_queue is loaded with lsmod or /proc/modules, and verify whether NFQUEUE rules are present with nft list ruleset, iptables-save, and ip6tables-save. After remediation, ensure the system has been rebooted into the patched kernel and that any temporary NFQUEUE mitigations are either retained intentionally or removed after patching. In test environments, regression-test applications that rely on NFQUEUE-based packet inspection, IDS/IPS, firewalling, or user-space packet verdict engines.

Typical attack path

1. Gain local access to an affected Linux system with enough privileges to use or influence netfilter NFQUEUE behavior.
2. Identify that nfnetlink_queue is available and that NFQUEUE rules or queue handling can be exercised.
3. Generate queued packets and verdict activity across queues to create concurrent access to nf_queue_entry objects.
4. Race verdict processing against object free operations so another CPU encounters a freed nf_queue_entry.
5. Trigger kernel use-after-free behavior in nfqnl_recv_verdict.
6. Cause a kernel crash for denial of service or attempt heap grooming to turn the memory corruption into local privilege escalation.

How to detect it

To determine whether exploitation may already have occurred, review kernel and system logs for use-after-free, KASAN, general protection fault, kernel oops, panic, or crash events involving nfnetlink_queue, nfqnl_recv_verdict, nfnetlink_rcv_msg, or netfilter verdict processing. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories such as /var/crash, and kernel dump analysis tooling if kdump is enabled. Look for repeated crashes or warnings temporally associated with NFQUEUE rule changes, unusual local user activity, suspicious processes with network administration privileges, or unexpected use/loading of the nfnetlink_queue module. Audit sources that may help include auditd logs for privilege changes, sudo usage, container runtime events granting NET_ADMIN-like privileges, and shell/process execution records showing nft, iptables, ip6tables, or custom NFQUEUE verdict programs. Because this is a memory-corruption vulnerability, absence of clear IOCs does not prove non-exploitation; kernel crashes may be the only observable artifact.

• BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict
• slab-use-after-free in nfqnl_recv_verdict
• nfqnl_recv_verdict+
• nfnetlink_queue
• nfnetlink_rcv_msg+
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• Oops:
• /var/crash/
• nf_queue_entry
• NETLINK_NETFILTER
• NFQUEUE
• iptables -j NFQUEUE
• ip6tables -j NFQUEUE
• nft list ruleset
• nfnetlink_queue

What your security team should do

• Inventory Linux systems using nfnetlink_queue or NFQUEUE rules, prioritizing internet-facing hosts, multi-user systems, container hosts, security appliances, firewalls, and packet-inspection workloads.
• Patch affected kernels using vendor-provided updates and reboot systems into the fixed kernel.
• Where patching is delayed, remove unnecessary NFQUEUE rules and restrict CAP_NET_ADMIN or other privileges that allow local users or workloads to exercise netfilter queue functionality.
• Monitor kernel logs for crashes, KASAN reports, slab use-after-free messages, and stack traces involving nfqnl_recv_verdict or nfnetlink_queue.
• Add detection for unexpected loading or use of nfnetlink_queue on systems that do not normally require NFQUEUE.
• Treat unexplained kernel oops or panic events involving nfnetlink_queue as potential security events and preserve kernel logs, crash dumps, and recent command/audit history for investigation.