CVE-2026-46324

What it actually does

This is a local race condition in the Linux kernel netfilter nf_tables subsystem. During hook or flowtable unregister operations, kernel lists could be modified without using the RCU-safe deletion primitive while another thread was concurrently walking the same list through netlink dump paths. That unsafe concurrent access can lead to stale pointer use, list corruption, kernel memory corruption, kernel crash, and potentially local privilege escalation. Exploitation requires local access with privileges sufficient to exercise nf_tables/netfilter operations, commonly CAP_NET_ADMIN or equivalent privileges in a namespace where nf_tables is available.

Why it matters to the business

Successful exploitation can allow a local attacker or compromised low-privileged workload to destabilize the host or potentially gain kernel-level control. For organizations running multi-user Linux systems, container platforms, CI runners, shared hosting, or systems with unprivileged user namespaces enabled, the operational risk is higher because a tenant, container, or local process may be able to reach the vulnerable kernel code path. The current public exploitation signal is low: EPSS is 0.00119, it is not listed in CISA KEV, and no public exploit maturity is reported, but kernel privilege-escalation bugs should still be prioritized on shared or exposed compute platforms.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the vulnerable kernel version is running and nf_tables/netfilter functionality is available. They then trigger concurrent nf_tables operations: one execution path unregisters netdev hooks or flowtable net hooks while another path performs netlink dump operations that walk the same hook list. Because the vulnerable code removes entries in a way that is unsafe for concurrent RCU readers, the dump path may observe a stale or inconsistent list element. With enough timing control, this can produce a use-after-free or list corruption condition in kernel memory. A simple exploit may only crash the kernel and cause denial of service; a more reliable exploit could attempt to shape freed kernel memory and turn the race into privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream fix for the nf_tables RCU list deletion issue, specifically the change that uses list_del_rcu() for netlink hook unregister paths in nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks. Because fixed package versions were not provided in the input, use the operating system vendor’s security advisory, kernel changelog, or distribution errata for the exact fixed kernel package. After installing the fixed kernel, reboot into it and remove or de-prioritize older vulnerable kernels from the bootloader where operationally appropriate. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting CAP_NET_ADMIN, disabling unprivileged user namespaces where feasible, preventing untrusted containers from acquiring network administration capabilities, and tightly controlling who can create or modify nftables rules, netdev hooks, and flowtables.

How to confirm the fix worked

Confirm the active running kernel is the patched vendor build, not merely that the package is installed. Validate with kernel version/package inventory, vendor advisory mapping, and reboot status checks. Review the kernel changelog or source package to confirm the nf_tables fix using list_del_rcu() for netlink hook unregister paths is included. On systems using live patching, verify the live patch explicitly covers this netfilter nf_tables race. Confirm exposure reduction by checking whether unprivileged user namespaces are enabled, whether containers can receive CAP_NET_ADMIN, and whether nftables/netfilter modules are loaded or usable by untrusted users. In test environments, run concurrent nftables create/delete and netlink dump workloads before and after patching to confirm the system remains stable, but avoid running untrusted proof-of-concept code on production systems.

Typical attack path

1. Gain local execution on a Linux host, container, or namespace with access to nf_tables/netfilter operations.
2. Obtain or abuse CAP_NET_ADMIN-equivalent privileges, potentially inside a user or network namespace if enabled.
3. Create nftables hooks, netdev chains, or flowtables that exercise the affected unregister paths.
4. Run concurrent netlink dump operations while unregistering hooks or flowtables to win the race window.
5. Trigger stale list traversal, memory corruption, or a kernel fault in the nf_tables/netfilter code path.
6. Use the resulting condition to crash the host or, if exploit primitives are available, escalate privileges to kernel/root level.

How to detect it

Look for evidence of attempted or successful local exploitation in kernel logs, audit logs, endpoint telemetry, and container/runtime logs. Kernel logs are the most important source: search dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dumps for Oops, BUG, KASAN, use-after-free, list corruption, general protection fault, or panic messages referencing nf_tables, netfilter, nft_netdev_unregister_hooks, __nft_unregister_flowtable_net_hooks, or flowtable hook unregister operations. In auditd or EDR telemetry, review bursts of nft, iptables-nft, or netlink activity by unusual users, containers, or service accounts, especially repeated creation/deletion of nftables tables, chains, flowtables, netdev hooks, or network namespaces. In container platforms, investigate workloads granted CAP_NET_ADMIN shortly before a node crash. Also correlate system instability with commands or processes that manipulate nftables rules. Absence of logs does not prove non-exploitation because a successful kernel crash or privilege escalation may leave limited artifacts.

• nft_netdev_unregister_hooks
• __nft_unregister_flowtable_net_hooks
• nf_tables
• netfilter
• flowtable
• list_del_rcu
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at net/netfilter
• list_add corruption
• list_del corruption
• RCU-list traversed
• nft
• iptables-nft
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching shared Linux hosts, container nodes, CI/CD runners, bastion hosts, and multi-tenant systems where local users or workloads may reach nf_tables functionality.
• Inventory systems running kernels that include nf_tables/netfilter support and map them to vendor advisories for the fixed kernel build.
• Reboot patched systems promptly and verify the running kernel version after maintenance.
• Restrict CAP_NET_ADMIN in containers and service units unless explicitly required.
• Disable or restrict unprivileged user namespaces where business requirements allow, because they can expand access to kernel networking attack surfaces.
• Monitor kernel logs for crashes, use-after-free reports, list corruption, or general protection faults involving nf_tables, netfilter, nft_netdev_unregister_hooks, or flowtable hook unregister paths.
• Treat unexplained kernel crashes on systems with recent nftables changes or untrusted local workloads as potential security events until ruled out.
• Because this issue is not in CISA KEV and has low EPSS, prioritize based on local attack surface and tenant isolation requirements rather than internet exposure alone.