CVE-2026-64079

What it actually does

This is a Linux kernel netfilter x_tables race condition that can expose an incompletely initialized table to per-network-namespace cleanup code. During arp/ip/ip6 table registration, the table can briefly be added to the namespace table list before its hook operations pointer is allocated. If network namespace teardown runs during that window, cleanup can pass a NULL hook-ops pointer to nf_unregister_net_hooks(), causing a kernel NULL pointer dereference or general protection fault. The most likely technical outcome is a local denial of service through kernel crash or panic; the provided information does not indicate reliable privilege escalation or remote code execution.

Why it matters to the business

Successful exploitation can crash affected Linux systems, disrupting workloads, containers, network services, and hosts that rely on netfilter, iptables, or network namespaces. The risk is higher on systems allowing untrusted local users, containers, or workloads to create network namespaces or manipulate netfilter state. EPSS is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but kernel-level crashes can still create significant availability impact in multi-tenant or containerized environments.

How an attack unfolds

An attacker would need local execution in a context capable of exercising network namespace lifecycle operations and netfilter/x_tables registration paths, commonly requiring CAP_NET_ADMIN in the relevant namespace or access to user namespaces that grant such capabilities inside a new namespace. The attacker repeatedly creates and tears down network namespaces while triggering iptables, ip6tables, or arptables table registration activity, attempting to hit the narrow race where the table is visible but its hook operations have not yet been allocated. If the race is won, namespace cleanup calls into nf_unregister_net_hooks() with a NULL operations pointer, causing a kernel fault and potentially crashing the host. No public exploit maturity is reported in the supplied data, and no named threat actors are associated with this issue.

How to fix it

Upgrade to a kernel version or vendor kernel package that includes the upstream fix for netfilter/x_tables allocation ordering, described as moving hook-ops allocation into the x_tables core so a table is never listed without valid operations and ensuring RCU synchronization during error unwind. Because no exact affected products or fixed package versions were provided, use your Linux distribution or kernel vendor advisory to identify the corrected build for CVE-2026-64079 or the patch titled "netfilter: x_tables: allocate hook ops while under mutex." If immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting creation of user namespaces where feasible, limiting CAP_NET_ADMIN in containers and services, disabling unneeded container privileges, and avoiding privileged containers that can manipulate host or namespace netfilter state. Mitigations should be treated as risk reduction, not a complete fix.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package version against the relevant distribution advisory or by confirming the kernel source/build includes the netfilter patch "x_tables: allocate hook ops while under mutex." Ensure systems have been rebooted into the patched kernel, since installing a kernel package alone does not remediate a running vulnerable kernel. Validate runtime exposure by checking whether untrusted users or containers can create user/network namespaces or obtain CAP_NET_ADMIN. Review kernel logs after patching for absence of new crashes involving nf_unregister_net_hooks(), ipt_unregister_table_pre_exit, iptable_mangle_net_pre_exit, ops_pre_exit_list, or cleanup_net under namespace churn. Avoid running race-condition proof-of-concept tests on production systems because successful validation may crash the host.

Typical attack path

1. Obtain local code execution on an affected Linux system, container host, or containerized workload with sufficient namespace/netfilter capabilities.
2. Create or enter a network namespace where netfilter table operations can be triggered.
3. Repeatedly invoke iptables, ip6tables, arptables, or related x_tables registration activity while concurrently creating and destroying network namespaces.
4. Attempt to trigger the race between table registration and per-network-namespace pre-exit cleanup.
5. Cause nf_unregister_net_hooks() to dereference a NULL hook operations pointer, leading to a kernel oops, panic, or host instability.

How to detect it

Look for evidence of prior exploitation primarily in kernel, system, and crash logs rather than application logs. Relevant sources include journalctl/kern.log/messages, dmesg, kdump/vmcore records, crash dump summaries, container host audit logs, and orchestration events showing repeated namespace or privileged container activity before a kernel fault. Search for kernel oops, panic, general protection fault, or NULL pointer dereference messages that include nf_unregister_net_hooks and the call trace functions ipt_unregister_table_pre_exit, iptable_mangle_net_pre_exit, ops_pre_exit_list, and cleanup_net. Correlate crashes with bursts of iptables/ip6tables/arptables executions, rapid network namespace creation/deletion, privileged container starts/stops, or unusual CAP_NET_ADMIN activity. Absence of these artifacts does not prove non-exploitation because a hard crash may truncate logs; check persistent journaling, remote syslog, hypervisor reset events, kdump artifacts, and monitoring alerts for unexplained reboots.

• general protection fault in nf_unregister_net_hooks
• RIP: nf_unregister_net_hooks
• nf_unregister_net_hooks+0xbc/0x150
• Call Trace: ipt_unregister_table_pre_exit
• ipt_unregister_table_pre_exit
• iptable_mangle_net_pre_exit
• ops_pre_exit_list
• cleanup_net
• NULL pointer dereference nf_unregister_net_hooks
• kernel panic nf_unregister_net_hooks
• Oops: general protection fault
• netfilter: x_tables: allocate hook ops while under mutex

What your security team should do

• Prioritize patching Linux container hosts, Kubernetes nodes, CI runners, shared bastion systems, and multi-user servers where untrusted code can run or create namespaces.
• Inventory systems using affected Linux kernels and confirm the currently booted kernel, not just the installed package version.
• Restrict CAP_NET_ADMIN from containers and workloads unless explicitly required.
• Disable or restrict unprivileged user namespaces where operationally feasible and supported by the distribution.
• Monitor kernel logs for crashes or general protection faults involving nf_unregister_net_hooks and x_tables cleanup functions.
• Review container runtime and orchestration policies to prevent privileged containers and unnecessary host network or netfilter access.
• Because this issue is not currently KEV-listed and has low EPSS, balance urgency with exposure: externally managed single-purpose hosts with no untrusted local execution are lower priority than shared or containerized systems.