CVE-2026-64095

What it actually does

This is a race condition in the Linux kernel batman-adv subsystem, specifically in the bridge loop avoidance (BLA) logic. Concurrent code paths can update the BLA request state and the global request counter without holding a common lock, allowing the counter to be decremented more than once or changed out of order relative to the request state. In practical terms, an attacker on an adjacent Layer 2 mesh/batman-adv network may be able to trigger inconsistent kernel state through crafted or timed BLA announcement/request handling. The expected security impact is primarily denial of service due to kernel instability, counter corruption, cleanup races, or crashes; limited integrity impact may also be possible within batman-adv bridge-loop handling behavior. The CVSS vector indicates adjacent-network exploitation, no authentication, no user interaction, low attack complexity, no confidentiality impact, low integrity impact, and high availability impact.

Why it matters to the business

Systems that use batman-adv mesh networking may be vulnerable to network-triggered disruption from an unauthenticated device on the same mesh or adjacent Layer 2 segment. Successful exploitation could interrupt mesh connectivity, destabilize affected hosts, or cause kernel crashes and reboots, which can affect industrial, wireless, embedded, IoT, edge, or community mesh deployments that depend on batman-adv for resilient network transport. This issue is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, exposure is concentrated in environments where untrusted or semi-trusted devices can join or reach the batman-adv mesh.

How an attack unfolds

An attacker first needs adjacency to an affected batman-adv mesh or Layer 2 network where batman-adv BLA traffic is processed. They then generate traffic or protocol conditions that cause BLA request and announcement handling paths to run concurrently against the same backbone gateway state. Because the vulnerable code updates the request_sent state and bla.num_requests counter without atomic synchronization, carefully timed events can cause one path to decrement the counter while another path is still in the process of incrementing or clearing state. Repeated triggering can corrupt internal accounting or interact with cleanup of a backbone gateway object, potentially leaving the kernel with inconsistent state. The most likely attacker outcome is denial of service through batman-adv malfunction, soft lockups, warnings, or kernel panic. There is no public evidence in the provided data of weaponized exploit code, active exploitation, named threat actors, or ransomware use.

How to fix it

Upgrade to a Linux kernel version that includes the upstream batman-adv fix for this race condition. The fix serializes updates to the BLA request state and request counter, introduces a stopped state for backbone-gateway cleanup, and avoids unsafe concurrent counter manipulation. Because exact affected and fixed downstream package versions were not provided, use the kernel packages from the relevant Linux distribution, appliance vendor, embedded firmware vendor, or long-term-stable kernel branch that explicitly includes the fix for this issue. Where immediate patching is not possible, reduce exposure by disabling batman-adv where it is not required, disabling or limiting BLA functionality if operationally feasible, restricting which devices can join the mesh, segmenting mesh participation to trusted nodes only, and monitoring for instability in batman-adv-enabled systems. Mitigations should not be treated as a full substitute for a patched kernel.

How to confirm the fix worked

Confirm exposure by checking whether the batman-adv kernel module is present and loaded, whether batman-adv interfaces are active, and whether BLA is enabled in the deployment. Validate remediation by confirming the running kernel build includes the vendor fix for this issue, not merely that a package is installed. On Linux systems, compare the running kernel version from `uname -r` with the vendor advisory or changelog, inspect distribution kernel changelogs for the batman-adv BLA race fix, and reboot into the fixed kernel after installation. Operational validation should include checking that mesh interfaces still function normally after upgrade and that kernel logs no longer show batman-adv BLA warnings, counter anomalies, soft lockups, use-after-free reports, or panic traces under normal mesh churn. If source validation is possible, confirm that BLA request state and request counter updates are protected by the corrected locking logic and that the stopped cleanup state is present.

Typical attack path

1. Gain access to the same batman-adv mesh, wireless mesh, or adjacent Layer 2 segment as the target system.
2. Confirm that the target is running a vulnerable Linux kernel with the batman-adv module loaded and BLA functionality in use.
3. Send or induce batman-adv BLA-related announcements, requests, bridge changes, or backbone-gateway churn to exercise vulnerable BLA code paths.
4. Trigger concurrent request, announcement, periodic work, and purge handling so request state and request counters are updated out of order.
5. Repeat the race condition until internal BLA accounting becomes inconsistent or cleanup races are hit.
6. Cause service degradation, loss of mesh forwarding stability, kernel warnings, soft lockups, or a system crash/reboot.

How to detect it

To determine whether this issue may already have been exploited, focus on kernel and network telemetry from systems using batman-adv. Review `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, persistent crash logs, kdump/vmcore data, and appliance firmware logs for batman-adv messages occurring near crashes, reboots, interface resets, or mesh instability. Look for kernel warnings, panics, soft lockups, KASAN/KCSAN reports, refcount/counter anomalies, use-after-free reports, or stack traces containing batman-adv BLA functions such as BLA announcement handling, request sending, purge, periodic work, or backbone gateway cleanup. Correlate these events with unusual mesh topology churn, repeated backbone gateway changes, new or unknown mesh participants, bursts of BLA announcements, or unexplained bridge-loop-avoidance activity. Network-level detection is difficult because exploitation depends on timing and valid-looking adjacent batman-adv behavior rather than a simple payload signature; prioritize anomaly detection around unexpected batman-adv control traffic and unexplained kernel instability on mesh nodes. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service attempt may leave only crash/reboot evidence.

• batman-adv
• BLA
• bridge loop avoidance
• bla.num_requests
• request_sent
• backbone_gw
• batadv_bla_send_request
• batadv_handle_announce
• batadv_bla_purge_backbone_gw
• batadv_bla_periodic_work
• BUG: kernel NULL pointer dereference
• kernel panic
• soft lockup
• WARNING: CPU
• KASAN
• KCSAN
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• /proc/modules

What your security team should do

• Inventory Linux systems, appliances, embedded devices, wireless mesh nodes, and edge devices that load or depend on the batman-adv kernel module.
• Prioritize patching systems where batman-adv mesh networks include untrusted devices, shared wireless media, public/community mesh participation, or physically accessible network segments.
• Apply vendor-provided kernel or firmware updates that include the batman-adv BLA race-condition fix, then reboot into the fixed kernel.
• If patching is delayed, restrict mesh membership to trusted devices, enforce wireless/L2 access controls, and disable batman-adv or BLA where not operationally required.
• Increase monitoring on batman-adv nodes for kernel crashes, soft lockups, repeated interface resets, unusual BLA activity, and unexpected backbone-gateway churn.
• Review recent kernel logs and crash dumps for evidence of batman-adv-related instability before and after remediation.
• Because there is no KEV listing, ransomware association, or known exploit maturity in the provided data, treat this as targeted-adjacent-risk rather than emergency internet-wide exposure, while still patching exposed mesh deployments promptly.