CVE-2026-64077

What it actually does

This is a local Linux kernel race condition in the netfilter ebtables code path. During ebtables table registration or removal, a table structure could be exposed before it was fully initialized, creating a window where another kernel execution path may operate on partially populated table operations. A local user with sufficient privileges to interact with ebtables or network namespace firewall configuration could potentially trigger memory corruption, kernel crash, or privilege escalation with kernel-level impact to confidentiality, integrity, and availability.

Why it matters to the business

Successful exploitation can let an attacker who already has local access increase control over the affected Linux system, potentially obtaining root-level privileges or causing outages through kernel instability. This is especially relevant for multi-user Linux hosts, container platforms, virtualization hosts, appliances, and systems where less-trusted users or workloads can create or modify network filtering rules. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no public exploit maturity reported, so urgency is lower than for actively exploited flaws, but kernel privilege-escalation issues should still be remediated through normal patch cycles.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and the ability to reach the ebtables/netfilter control path, typically through privileges such as CAP_NET_ADMIN, root inside a permissive container, or another delegated network-administration capability. The attacker then repeatedly creates, replaces, or removes ebtables bridge filtering tables while racing concurrent kernel operations that reference the table. If timed correctly, the kernel may act on a partially initialized or inconsistently removed ebtables structure. Depending on kernel build, memory layout, and exploit reliability, this may result in a kernel oops or panic, or may be shaped into a local privilege-escalation primitive that gives the attacker elevated control over the host.

How to fix it

Upgrade to a Linux kernel version that includes the upstream ebtables two-stage removal fix for this issue. Use vendor-provided kernel updates for the relevant distribution or appliance rather than applying isolated patches where possible. No exact fixed package versions were provided in the input, so consult the operating system or kernel vendor advisory for the corrected kernel build. As mitigations until patching is complete, restrict local shell access, limit CAP_NET_ADMIN and other network-administration capabilities, avoid running containers with unnecessary privileged mode or broad Linux capabilities, disable or block use of ebtables/bridge netfilter functionality where operationally feasible, and enforce least privilege for users and workloads that can manage firewall rules.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the ebtables two-stage removal fix for this vulnerability. Validate with package-manager metadata, vendor advisory references, and the active running kernel version, not only the installed package list; reboot if required so the patched kernel is active. Review whether ebtables and bridge netfilter modules are present or loaded, and verify that untrusted users or containers do not have CAP_NET_ADMIN or privileged-container access. If using container orchestration, confirm security policies prevent unnecessary host network administration capabilities. Where supported, run vendor vulnerability scanners or compliance tools that map the active kernel package to the fixed release.

Typical attack path

1. Gain local shell, container execution, or code execution on a vulnerable Linux system.
2. Obtain or already possess permission to interact with netfilter/ebtables, such as CAP_NET_ADMIN or equivalent namespace/network administration privileges.
3. Load or access ebtables-related bridge netfilter functionality if it is available on the system.
4. Rapidly create, replace, and delete ebtables tables or rules to trigger the race window in table registration/removal.
5. Attempt to cause the kernel to dereference or operate on a partially initialized table structure.
6. Use the resulting crash for denial of service or, if a reliable exploit primitive is available, escalate privileges to root/kernel-level control.

How to detect it

Look for evidence of local attempts to manipulate ebtables or bridge netfilter immediately before kernel instability, privilege changes, or unexpected reboots. Useful sources include kernel logs, systemd journal, auditd command-execution logs, sudo logs, shell history where available, endpoint telemetry, container runtime audit events, and orchestration audit logs showing privileged containers or CAP_NET_ADMIN grants. Investigate kernel oops, panic, general protection fault, use-after-free, NULL pointer dereference, or slab corruption messages mentioning ebtables, bridge netfilter, x_tables, or netfilter table registration/removal. Also review process execution for repeated ebtables, iptables-legacy, nft, modprobe, rmmod, or namespace commands launched by non-administrative users or unexpected containers. Because there are no known public exploit indicators in the input, detections should be treated as behavioral and forensic leads rather than definitive compromise indicators.

• ebtables
• ebtables-legacy
• /sbin/ebtables
• /usr/sbin/ebtables
• modprobe ebtable_filter
• modprobe ebtable_nat
• modprobe ebtable_broute
• modprobe ebtables
• rmmod ebtable_filter
• rmmod ebtable_nat
• rmmod ebtable_broute
• CAP_NET_ADMIN
• privileged=true
• --privileged
• --cap-add=NET_ADMIN
• kernel: BUG: kernel NULL pointer dereference
• kernel: general protection fault
• kernel: unable to handle kernel paging request
• kernel: kernel panic
• kernel: Oops
• kernel: slab-out-of-bounds
• kernel: use-after-free
• ebtable_filter
• ebtable_nat
• ebtable_broute
• bridge netfilter
• netfilter: ebtables

What your security team should do

• Prioritize patching Linux systems where untrusted users, CI jobs, containers, or third-party workloads have local execution or network-administration capabilities.
• Inventory systems with ebtables or bridge netfilter usage, including container hosts, Kubernetes nodes, virtualization platforms, network appliances, and multi-tenant Linux servers.
• Remove CAP_NET_ADMIN, privileged container mode, host networking, and unnecessary namespace privileges from workloads that do not explicitly require them.
• Schedule kernel updates through the normal emergency or expedited maintenance process for exposed multi-user/container hosts, even though KEV and EPSS signals are currently low.
• Monitor kernel logs for crashes, oops messages, or suspicious ebtables activity until patched.
• Ensure systems are rebooted into the patched kernel after updates and that old vulnerable kernels are not still active.
• Document compensating controls if immediate patching is not possible, including capability restrictions and reduced local access.