CVE-2026-64078

What it actually does

This is a local Linux kernel race condition in the netfilter x_tables table teardown path. During module removal, x_tables state could be detached from packet processing and unlinked from active per-network namespace table lists before all cleanup stages completed. A local user able to exercise relevant netfilter socket operations during this teardown window could trigger inconsistent kernel state, potentially leading to memory corruption, kernel crash, or privilege escalation. The CVSS vector indicates local access with low attack complexity and low privileges, with potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a user or compromised low-privilege process on a Linux system to gain elevated privileges or destabilize the host. The most likely operational risks are host compromise, service outage from a kernel crash, and loss of trust in workloads running on affected systems. Because this is a kernel flaw, impact can extend to any application or container workload relying on the affected host kernel. It is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so urgency should be driven primarily by local exposure and kernel lifecycle rather than evidence of active broad exploitation.

How an attack unfolds

An attacker first needs local code execution or a low-privileged account on an affected Linux host. They then attempt to trigger concurrent netfilter x_tables activity while a relevant module or table is being removed. The exploit strategy is to race userspace set/get socket option operations against x_tables table unregister and module teardown logic. If the race is won, the kernel can enter an inconsistent state because the table has been removed from active lookup paths while cleanup has not fully completed. Depending on kernel build, timing, and memory layout, this may result in denial of service through a kernel crash or may be shaped into memory corruption useful for privilege escalation. There is no public exploit maturity reported in the supplied data, so exploitation should be treated as plausible but not currently commoditized.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the x_tables unregister teardown path, specifically the change introducing and using xtables_unregister_table_exit. If vendor kernel packages are used, update through the distribution or appliance vendor once their fixed kernel is available. No exact affected product list or fixed package versions were provided, so remediation should be verified against the relevant vendor advisory, kernel changelog, or backport status. Where immediate patching is not possible, reduce local attack surface by limiting shell access, restricting untrusted workloads, minimizing module loading/unloading, limiting CAP_NET_ADMIN and other network administration capabilities in containers, and preventing unnecessary netfilter module manipulation by non-administrative users. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix. Validate by checking the active kernel version with uname and comparing it to the vendor-fixed release or by confirming the vendor advisory states the running kernel build includes the x_tables unregister fix. On source-built kernels, verify the netfilter x_tables code contains the staged unregister cleanup using xtables_unregister_table_exit. Also confirm systems have rebooted into the patched kernel. For exposure validation, inventory Linux hosts using netfilter/iptables/x_tables functionality and identify hosts where untrusted local users, containers, or workloads can execute code or obtain network administration capabilities.

Typical attack path

1. Obtain local execution on an affected Linux system, such as through a compromised user account, application shell, or container escape prerequisite.
2. Identify whether netfilter x_tables functionality and removable related modules are present and usable on the host.
3. Run code that repeatedly performs x_tables-related set/getsockopt operations while table or module teardown is occurring.
4. Attempt to win the race between userspace netfilter operations and kernel table unregister cleanup.
5. Trigger kernel memory corruption, inconsistent state, or crash.
6. If exploit primitives are reliable, escalate privileges or disable host availability.

How to detect it

There are no reliable public exploitation indicators for this vulnerability from the supplied data. Detection should focus on behavioral evidence of attempted local kernel exploitation: unusual use of rmmod or modprobe -r for netfilter-related modules, repeated iptables/ip6tables or x_tables operations, high-volume getsockopt/setsockopt activity involving netfilter, kernel warnings, oops, panics, or unexpected reboots around the same time. Useful log sources include Linux audit logs, syslog/journald, kernel ring buffer logs, EDR process telemetry, command-line history where available, container runtime audit events, and eBPF/auditd syscall telemetry for delete_module, init_module, finit_module, setsockopt, and getsockopt. Investigate low-privileged accounts or containerized processes invoking module removal tools or performing unusual netfilter manipulation. Absence of these artifacts does not prove non-exploitation because a successful local kernel exploit may leave limited forensic evidence.

What your security team should do

• Prioritize patching multi-user Linux servers, container hosts, CI runners, bastion systems, shared compute platforms, and any host running untrusted workloads.
• Track vendor advisories for the exact distribution kernel package that backports the x_tables fix, then deploy and reboot into the fixed kernel.
• Restrict CAP_NET_ADMIN and privileged container usage; avoid granting broad network administration capabilities to containers or untrusted services.
• Limit access to module loading and unloading operations to trusted administrators only, and monitor delete_module/init_module activity on sensitive systems.
• Use endpoint telemetry or auditd/eBPF monitoring to detect unusual combinations of module removal and high-volume netfilter socket option activity.
• Because there is no KEV listing, ransomware association, or mature exploit signal in the supplied data, treat this as a high-impact local privilege escalation risk rather than an internet-wide emergency.