CVE-2026-64412

What it actually does

This is a Linux kernel netfilter/ebtables input-validation flaw where an ebtables module name can be passed to request_module() without guaranteed null termination. A local attacker able to exercise the affected ebtables code path can supply a crafted module name that fills the expected buffer without a terminating byte, causing the kernel to treat adjacent memory as part of the string. Depending on memory layout and kernel configuration, this can result in kernel memory over-read, unintended module-load attempts, information exposure, or a kernel fault/panic leading to denial of service. The CVSS vector indicates local exploitation, low attack complexity, low privileges, no user interaction, and high confidentiality and availability impact, with no expected direct integrity impact.

Why it matters to the business

Successful exploitation can expose sensitive kernel memory or destabilize the host, potentially causing service outages on systems that rely on the affected Linux kernel. The risk is most relevant for multi-user Linux systems, virtualization/container platforms, and environments where unprivileged user namespaces or delegated network administration capabilities allow less-trusted local users to reach netfilter/ebtables functionality. This issue is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so immediate internet-wide exploitation pressure appears limited; however, kernel-local bugs can still be high-impact where local code execution is already possible or where containers share the host kernel.

How an attack unfolds

An attacker first obtains local execution on a Linux system, or access to a confined workload that can interact with netfilter/ebtables through available capabilities or namespace configuration. The attacker then submits a crafted ebtables/netfilter request containing a module or extension name that is the maximum expected length and deliberately lacks a null terminator. The vulnerable kernel code fails to validate the string length before passing the value to request_module(). request_module() then interprets memory beyond the intended buffer as part of the module name until a null byte is encountered. This can leak adjacent kernel memory through module-load paths or logs, trigger malformed module autoload attempts, or cause a kernel exception if the over-read crosses invalid memory. In the worst operational case, the attacker can crash the kernel and deny service to all workloads on that host.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the ebtables null-termination validation in netfilter. Because no product-specific fixed versions were provided, use vendor advisories for the exact fixed kernel package for each distribution or appliance and prioritize systems that allow local users, containers, or delegated network administration. If immediate patching is not possible, reduce exposure by restricting local shell access, disabling or tightly controlling unprivileged user namespaces where operationally feasible, limiting CAP_NET_ADMIN assignment to trusted workloads only, preventing untrusted containers from managing host or namespace firewall rules, and ensuring module autoloading is not unnecessarily exposed to untrusted users. Reboot into the fixed kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, is at or above the vendor-fixed version. Check distribution security advisories and changelogs for the netfilter/ebtables fix referencing module-name null termination or request_module() length validation. Validate that systems have rebooted into the fixed kernel using standard kernel version checks. Where source or build metadata is available, confirm the ebtables code explicitly checks module-name length or guarantees null termination before calling request_module(). For exposure validation, review whether untrusted local users or containers can obtain CAP_NET_ADMIN, whether unprivileged user namespaces are enabled, and whether ebtables/netfilter interfaces are available in namespaces used by untrusted workloads.

Typical attack path

1. Gain local code execution on a Linux system or in a workload sharing the host kernel.
2. Obtain a path to invoke ebtables/netfilter functionality, such as CAP_NET_ADMIN in the relevant namespace or an environment with permissive unprivileged user namespaces.
3. Craft an ebtables request with a module, match, target, or table-related name that fills the accepted field and omits null termination.
4. Submit the crafted request to the kernel through the ebtables/netfilter interface.
5. Trigger request_module() with the unterminated string, causing an over-read into adjacent kernel memory.
6. Observe resulting information exposure, abnormal module-load behavior, kernel warnings/oops messages, or system crash.

How to detect it

There are no public, reliable, exploit-specific indicators for this vulnerability from the provided intelligence. Detection should focus on behavioral evidence: audit local use of ebtables and netfilter configuration interfaces, especially by non-administrative users or containerized processes; review kernel logs for oops, panic, general protection fault, page fault, or BUG messages occurring near ebtables activity; review module-loading logs for unusual, very long, malformed, non-printable, or unexpected module names following ebtables/netfilter operations; and correlate crashes with recent namespace creation, CAP_NET_ADMIN use, container start events, or firewall-rule manipulation. Useful log sources include kernel ring buffer logs, system journal kernel facility, auditd syscall and capability records, process execution logs for ebtables/nft/iptables tooling, container runtime logs, and module-loader/modprobe logs. For forensic review, preserve dmesg/journal output, audit logs, core/kdump artifacts if configured, and recent process execution history involving ebtables or network namespace tooling.

What your security team should do

• Inventory Linux systems and kernel versions, prioritizing multi-user hosts, container hosts, Kubernetes/container worker nodes, virtualization platforms, and systems where untrusted users can execute local code.
• Track vendor kernel advisories and apply the fixed kernel package as soon as available; reboot systems into the patched kernel.
• Restrict CAP_NET_ADMIN and similar network-administration privileges to trusted workloads and administrators only.
• Review and, where feasible, disable or constrain unprivileged user namespaces to reduce local-kernel attack surface.
• Monitor for abnormal ebtables activity, unexpected module autoload attempts, malformed module names, and kernel oops/panic events.
• Treat crashes or unusual module-load failures following ebtables activity as potentially suspicious and preserve kernel logs for forensic review.
• Because this is not currently KEV-listed and EPSS is low, prioritize based on local-code-execution exposure and shared-kernel risk rather than public internet exposure alone.