Cloudanix VulnDB

CVE-2026-64076

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in some Linux systems could let someone who already has limited access crash the machine or potentially gain full control, so affected systems should be updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

This vulnerability is a race condition in the Linux kernel netfilter bridge ebtables initialization path. During module initialization, ebtables socket options could become globally reachable before the subsystem was fully initialized. A local attacker with the ability to invoke the relevant netfilter/ebtables socket option interface during this narrow initialization window may be able to interact with partially initialized kernel state, potentially leading to memory corruption, kernel crash, or privilege escalation. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privileged process on a Linux host to gain elevated privileges or crash the system, which can lead to host takeover, service disruption, and increased blast radius after an initial compromise. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and no public exploit maturity is reported, so broad active exploitation is not indicated; however, kernel privilege-escalation flaws are still important because they can turn limited footholds into full system compromise.

How an attack unfolds

An attacker first needs local execution on an affected Linux system, such as through a shell, compromised application process, container escape precondition, or other low-privileged foothold. The attacker then attempts to trigger loading or initialization of the bridge ebtables/netfilter module while concurrently invoking the exposed ebtables socket option interface. Because the socket option registration could occur before initialization was fully complete, the attacker races access to code paths that assume internal structures are ready. If the race is won reliably enough, the result may be denial of service through a kernel fault or, depending on memory state and exploit technique, corruption of kernel data that could be used to elevate privileges. Exploitation is local and timing-dependent, and there is no indication from the provided data that public weaponized exploit code is available.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the ebtables initialization ordering issue, where socket option registration occurs only after core ebtables initialization is complete. Because no product-specific fixed versions were provided, use vendor advisories for the relevant Linux distribution or kernel branch to identify the corrected package version. Reboot into the patched kernel after installation; simply installing the package is insufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container boundaries, disabling or preventing automatic loading of unused bridge/netfilter/ebtables modules where operationally feasible, and monitoring for unexpected use of ebtables-related functionality.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is updated to a vendor release containing the fix. Validate with commands such as `uname -a` and distribution package tools, for example `rpm -q kernel`, `dpkg -l 'linux-image*'`, or the vendor's kernel live-patching status tools where applicable. Review vendor advisories or changelogs for references to netfilter bridge ebtables initialization, `eb_tables`, or the relevant CVE. If mitigating by disabling unused functionality, verify whether the `ebtables`, `ebtable_filter`, `ebtable_nat`, `ebtable_broute`, or related bridge netfilter modules are loaded with `lsmod`, and confirm module-load restrictions persist after reboot. For exposure testing, verify whether unprivileged or low-privileged users can trigger relevant ebtables/netfilter paths on representative systems, but avoid running untrusted proof-of-concept code on production hosts.

Typical attack path

  1. Obtain local code execution on a Linux system with an affected kernel.
  2. Identify whether bridge netfilter/ebtables functionality is available or can be triggered to load.
  3. Attempt to race ebtables module initialization while issuing relevant netfilter socket option calls.
  4. Trigger access to partially initialized kernel state.
  5. Cause a kernel crash or attempt to manipulate resulting memory corruption for privilege escalation.
  6. Use elevated privileges, if obtained, to disable defenses, access sensitive data, or persist on the host.

How to detect it

There are no highly specific public indicators of exploitation from the provided data, and successful exploitation of a kernel race condition may leave few application-level traces. Focus detection on precursor and consequence evidence: audit logs showing local users or processes invoking ebtables, bridge netfilter, or raw netfilter socket option activity; kernel logs showing module loading followed by oops, panic, general protection faults, use-after-free-like symptoms, or crashes involving `ebtables`, `eb_tables`, `netfilter`, or bridge networking; and unexpected loading of ebtables-related modules on hosts that do not normally use them. Review `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, auditd logs, EDR process telemetry, command history, and module-load events. Pay particular attention to low-privileged accounts executing networking utilities, compilers, temporary binaries, or scripts shortly before kernel instability. If exploitation is suspected, preserve volatile evidence, collect kernel logs and crash dumps, compare loaded modules against baseline, and investigate for follow-on privilege escalation such as new root-owned files, altered sudoers entries, new setuid binaries, modified systemd units, or disabled security tooling.

  • eb_tables
  • ebtables
  • ebtable_filter
  • ebtable_nat
  • ebtable_broute
  • modprobe eb_tables
  • modprobe ebtables
  • kernel: BUG:
  • kernel: Oops:
  • kernel panic
  • general protection fault
  • unable to handle kernel NULL pointer dereference
  • nf_register_sockopt
  • netfilter: bridge
  • /proc/net/ebt_tables_names
  • /proc/net/ebt_tables_targets
  • /proc/net/ebt_tables_matches

What your security team should do

  • Prioritize patching internet-facing, multi-user, container-hosting, CI/CD runner, shared compute, and high-trust Linux systems, because local privilege escalation materially increases post-compromise impact.
  • Track Linux distribution advisories for fixed kernel package versions and ensure systems reboot into the corrected kernel.
  • Inventory systems with bridge netfilter, ebtables, container networking, virtualization, or Kubernetes networking components, as these are more likely to rely on the affected subsystem.
  • Restrict local access and untrusted workload execution on unpatched systems until remediation is complete.
  • Where operationally safe, disable or block loading of unused ebtables/bridge netfilter modules as a temporary mitigation.
  • Monitor for kernel crashes, oops messages, suspicious ebtables activity, and unexpected module loading on unpatched systems.
  • Treat suspicious exploitation attempts as potential privilege-escalation activity and perform host-level forensic review if crashes or anomalous module activity are observed.

The record

In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: eb_tables: close module init race sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nf_register_sockopt() completes, the sockopts are exposed globally. sockopt has to be registered last, just like in ip/ip6/arptables.

Affected packages

Ecosystem Package Introduced Fixed