CVE-2026-64413

What it actually does

This Linux kernel flaw is in the netfilter ebtables table translation path. Under a sparse cpu_possible_mask, allocation for per-CPU ebtables chainstack entries can skip some CPU indexes. If a later vmalloc_node() allocation fails, cleanup may call vfree() on an uninitialized chainstack pointer for a skipped CPU. In the worst case, that can produce kernel memory corruption, potentially causing a local denial of service or, depending on allocator state and exploitability, local privilege escalation or compromise of kernel memory integrity. The published CVSS indicates local access, low privileges, no user interaction, and high confidentiality, integrity, and availability impact, but exploitation is considered high complexity and no public exploit maturity is indicated.

Why it matters to the business

Successful exploitation would affect the operating system kernel, so the consequence could be severe on an individual host: system crash, service interruption, or potential elevation from a low-privileged local account to kernel-level control. Practical risk is reduced because exploitation requires local access, a specific CPU topology condition, and an unlikely allocation-failure path; the EPSS score is very low and the issue is not listed in CISA KEV or known ransomware use. Organizations should still remediate through normal kernel update cycles, prioritizing multi-user Linux systems, container hosts, virtualization hosts, build servers, and systems where untrusted users or workloads can trigger netfilter or ebtables functionality.

How an attack unfolds

An attacker first needs code execution as a low-privileged local user or through a compromised workload on a Linux host. They then attempt to reach ebtables/netfilter table translation code, typically by invoking tooling or kernel interfaces that load, replace, or translate Ethernet bridge filtering rules. Exploitation depends on the host having a sparse possible-CPU mask, such as CPU indexes where one possible CPU ID is absent between possible CPUs, and on forcing or encountering a vmalloc_node() failure after some per-CPU chainstack entries have been allocated. During error cleanup, the kernel may attempt to free an uninitialized pointer corresponding to a skipped CPU slot. If the bad free only triggers a fault, the attacker may crash the kernel; if memory layout and allocator behavior are favorable, the primitive could potentially be shaped into kernel memory corruption and privilege escalation. No known public exploitation, named threat actor use, KEV listing, or ransomware campaign use is currently indicated.

How to fix it

Apply vendor-supplied Linux kernel updates that include the ebtables chainstack initialization fix. The upstream fix zeroes the chainstack array so cleanup of skipped CPU entries is safe. Because no affected product list or fixed package versions were provided, use distribution advisories for the exact package names and versions, such as kernel, kernel-core, linux-image, linux-generic, or vendor-specific kernel packages. After installing the updated kernel, reboot into the fixed kernel; merely installing the package is not sufficient if the host continues running the old kernel. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, enforcing least privilege, and limiting access to capabilities or administrative paths that can manipulate netfilter/ebtables state, especially CAP_NET_ADMIN in containers and namespaces. Consider disabling or avoiding bridge netfilter/ebtables functionality where it is not operationally required, subject to vendor guidance and change-control testing.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is at or above the vendor-fixed version. Use distribution package metadata and vendor advisories to map the running kernel release to the fixed build. On Linux systems, compare uname -r with installed kernel package versions and confirm the host has been rebooted after patching. Validate that ebtables/netfilter functionality still works as expected after the update if bridge firewalling is used. To assess exposure before patching, determine whether ebtables or bridge netfilter modules are present or loaded and whether untrusted users, containers, or services have paths to CAP_NET_ADMIN or ebtables rule manipulation. Review CPU topology for sparse possible CPUs by inspecting /sys/devices/system/cpu/possible; sparse values such as 0,2 or 0-1,3 may be more relevant than contiguous ranges. Absence of a sparse CPU mask or ebtables use reduces practical exploitability but does not replace patching.

Typical attack path

1. Obtain local low-privileged execution on a Linux system, directly or through a compromised service, shell, container, or user account.
2. Determine whether the system has a CPU topology with a sparse cpu_possible_mask relevant to the vulnerable code path.
3. Trigger ebtables/netfilter table translation or rule replacement operations from a context permitted to interact with bridge firewalling functionality.
4. Create memory pressure or otherwise attempt to induce vmalloc_node() failure during allocation of per-CPU chainstack entries.
5. Cause the cleanup path to vfree() an uninitialized chainstack pointer for a skipped CPU index.
6. Leverage the resulting kernel fault for denial of service, or attempt to shape memory corruption into local privilege escalation if feasible.

How to detect it

Look for evidence of attempted local exploitation by correlating ebtables/netfilter activity with kernel memory faults or crashes. Relevant log sources include the kernel ring buffer, system journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs, sudo logs, shell history where appropriate, endpoint telemetry, and container runtime or Kubernetes audit logs for privileged networking operations. Search for kernel oops, panic, general protection fault, invalid pointer dereference, BUG, KASAN, slab, vmalloc, vfree, or netfilter/ebtables-related errors near executions of ebtables, iptables-nft, nft, brctl, bridge, or container networking processes. Review audit events for use of CAP_NET_ADMIN, namespace creation, privileged containers, and commands modifying bridge firewall rules. Because this issue has no known public exploit and the bug is a kernel cleanup-path memory-corruption condition, there are no reliable network IOCs; detection should focus on host telemetry, crash artifacts, and suspicious local attempts to manipulate ebtables/netfilter while inducing memory pressure.

• ebtables
• ebtables-restore
• iptables-nft
• nft
• br_netfilter
• ebtable_filter
• ebtables:
• netfilter:
• chainstack
• vmalloc_node
• vfree
• kernel BUG
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• Oops:
• Kernel panic
• KASAN:
• slab-out-of-bounds
• use-after-free
• /sys/devices/system/cpu/possible
• /proc/net/bridge
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Patch affected Linux kernels through the normal operating-system update process and reboot into the fixed kernel.
• Prioritize systems with local multi-user access, container workloads, virtualization roles, bridge networking, Kubernetes/container networking components, or delegated CAP_NET_ADMIN.
• Audit containers and services for unnecessary CAP_NET_ADMIN or other privileges that can manipulate netfilter, ebtables, bridge networking, or network namespaces.
• Monitor for kernel crashes, oopses, panics, or suspicious ebtables/netfilter rule changes on unpatched systems.
• Use vendor advisories to identify exact fixed kernel builds for each Linux distribution in use, since no product-specific fixed versions were provided in the input.
• Treat exploitation likelihood as currently low due to low EPSS, no KEV status, no known ransomware use, and no public exploit maturity, but do not ignore the issue because successful kernel exploitation can have full-host impact.