CVE-2026-64411

What it actually does

This is a local Linux kernel netfilter/ebtables flaw caused by passing a user-controlled 32-byte ebtables table name to lookup and module-loading code without guaranteeing NUL termination. If the lookup misses, the kernel formats a module request using the unterminated name, causing vsnprintf() to read past the intended stack field until it encounters a zero byte. The direct technical result is a kernel stack out-of-bounds read. Depending on build options and runtime conditions, this may expose adjacent kernel stack data through module-request paths, kernel diagnostics, audit/logging, or crash reports, and may also trigger a kernel warning, KASAN report, or denial of service. The issue is local, requires some ability to call the relevant netfilter/ebtables setsockopt path, and is most relevant where users can obtain CAP_NET_ADMIN in a network namespace, such as systems with unprivileged user namespaces enabled.

Why it matters to the business

Successful exploitation can allow a local attacker or compromised low-privilege workload to read unintended kernel memory or destabilize the host. In shared Linux environments, container hosts, developer workstations, CI runners, and multi-user servers, this increases the risk that a local foothold becomes a host-level confidentiality or availability incident. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS at the time of assessment, and has no reported public exploit maturity, so urgency is primarily driven by local multi-tenancy, exposure of untrusted users or containers, and whether unprivileged user namespaces are enabled.

How an attack unfolds

An attacker first gains local code execution on a Linux system, for example through a shell, compromised application, container escape staging point, or low-privilege user account. They then access the ebtables/netfilter control path, typically requiring CAP_NET_ADMIN in the relevant network namespace. The attacker submits an ebtables counter update or compatible counter update request containing a table name that fills the fixed 32-byte field without a terminating NUL byte and is chosen to miss existing table lookup. On the miss path, the kernel attempts to request an ebtables-related module using a formatted string built from the attacker-controlled name. Because the name is not terminated, formatting code reads past the table-name field into adjacent stack memory. The attacker’s practical objective is to cause sensitive kernel stack bytes to be consumed by diagnostic/module-request handling or to trigger a crash or KASAN-detected fault. There is no indication from the provided data that this vulnerability directly provides arbitrary kernel write or remote code execution.

How to fix it

Apply a Linux kernel update that includes the netfilter/ebtables fix titled "netfilter: ebtables: terminate table name before find_table_lock()". Where exact vendor package versions are not available, use the latest security kernel from the Linux distribution or appliance vendor and reboot into the fixed kernel. If immediate patching is not possible, reduce exploitability by restricting local shell access, limiting container privileges, disabling or restricting unprivileged user namespaces where operationally feasible, avoiding CAP_NET_ADMIN for untrusted workloads, and blocking untrusted containers from using host networking or broad network namespace capabilities. Disable or unload unused ebtables/bridge netfilter functionality only if it is not required and the change is validated against production networking and firewall dependencies. Treat mitigations as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated and the host has been rebooted if required. Review vendor advisories or kernel changelogs for the fix string "netfilter: ebtables: terminate table name before find_table_lock()". For source-based validation, verify that copied ebtables table-name fields are explicitly NUL-terminated before calls into find_table_lock(), including compat paths such as compat_copy_ebt_replace_from_user(). Assess exposure by checking whether ebtables/bridge netfilter support is enabled or loadable and whether untrusted local users or containers can obtain CAP_NET_ADMIN in a network namespace. In controlled non-production testing with kernel sanitizers or debug logging, malformed maximum-length table-name requests should no longer produce KASAN stack-out-of-bounds reports in lib/vsprintf.c or net/bridge/netfilter/ebtables.c.

Typical attack path

1. Obtain local execution on a Linux host or inside an environment that can reach the host kernel netfilter interfaces.
2. Acquire or already possess the ability to perform ebtables/netfilter setsockopt operations, commonly CAP_NET_ADMIN in a network namespace.
3. Craft an ebtables update_counters, compat_update_counters, or related compat replacement request with a non-NUL-terminated 32-byte table name.
4. Ensure the supplied table name does not match an existing ebtables table so the lookup miss path invokes module-request logic.
5. Trigger the vulnerable path, causing kernel string formatting to read beyond the intended stack buffer.
6. Collect any exposed data from logs, module request artifacts, crash reports, or kernel diagnostics, or use the condition to cause host instability.

How to detect it

Look for evidence of attempted local exploitation in kernel logs, syslog, journald, auditd, eBPF telemetry, EDR process telemetry, and crash-dump systems. The strongest indicators are kernel sanitizer or crash messages showing stack out-of-bounds reads in lib/vsprintf.c during ebtables counter updates, call traces involving do_update_counters(), compat_update_counters(), find_table_lock(), find_inlist_lock(), __request_module(), or net/bridge/netfilter/ebtables.c, and suspicious module autoload attempts for module names beginning with ebtable_ followed by unusual, long, non-printable, or malformed characters. Also review audit logs for local processes repeatedly invoking setsockopt on raw/IP sockets in proximity to ebtables failures, especially from untrusted users, containers, build jobs, or unexpected processes. Absence of these artifacts does not prove non-exploitation because the primitive may leave minimal evidence on non-debug kernels; prioritize correlation between local process execution, namespace/capability changes, ebtables activity, module-load requests, and kernel warnings or crashes.

• KASAN: stack-out-of-bounds in string
• Read of size 1 at addr
• lib/vsprintf.c:648
• lib/vsprintf.c:730
• vsnprintf
• __request_module
• do_update_counters.isra.0
• update_counters
• compat_update_counters
• do_ebt_set_ctl
• net/bridge/netfilter/ebtables.c:371
• net/bridge/netfilter/ebtables.c:380
• net/bridge/netfilter/ebtables.c:1440
• net/bridge/netfilter/ebtables.c:2573
• nf_setsockopt
• raw_setsockopt
• __sys_setsockopt
• ebtable_

What your security team should do

• Prioritize patching on multi-user Linux hosts, container hosts, Kubernetes nodes, CI/CD runners, bastion systems, and any servers that execute untrusted local code.
• Inventory systems with unprivileged user namespaces enabled and workloads granted CAP_NET_ADMIN; treat those systems as higher risk until patched.
• Update to the latest vendor-supported kernel containing the ebtables table-name termination fix and verify systems have rebooted into the fixed kernel.
• Remove CAP_NET_ADMIN and privileged-container permissions from workloads that do not strictly require them.
• Monitor kernel, audit, syslog, and crash-reporting sources for KASAN stack-out-of-bounds messages, suspicious ebtables module requests, or repeated failed ebtables table operations.
• If suspicious activity is found, preserve kernel logs, audit logs, crash dumps, process execution history, and container runtime metadata for investigation.
• Because this is not currently KEV-listed and has very low EPSS, use risk-based scheduling for single-user or tightly controlled systems, but do not defer patching on shared or containerized infrastructure.