CVE-2026-64093

What it actually does

This is a race condition in the Linux kernel batman-adv subsystem, specifically in the throughput meter sender cleanup path. A timer used by the tp_meter logic could be re-armed by one execution context while another context was shutting the sender down and releasing the associated reference. That creates a use-after-free style condition in kernel context: a timer callback may later run against state that has already been cleaned up. Because this occurs in kernel networking code, successful exploitation can plausibly cause kernel memory corruption, system crash, denial of service, and potentially privilege-equivalent kernel code execution depending on kernel build, mitigations, timing, and allocator state.

Why it matters to the business

Systems that use the batman-adv mesh networking kernel module may be exposed to unauthenticated adjacent-network attacks that can disrupt network nodes or, in worst cases, compromise the operating system at kernel level. The practical exposure is usually limited to hosts, routers, appliances, embedded devices, or mesh nodes where batman-adv is loaded and reachable from an adjacent mesh/network segment. Although EPSS is currently low and the issue is not listed in CISA KEV, the high CVSS score reflects serious consequences if the vulnerable code path is reachable.

How an attack unfolds

An attacker needs network adjacency to a system participating in or processing batman-adv traffic. The attacker triggers tp_meter activity and ACK handling while causing sender shutdown or cleanup to occur at a carefully timed moment. In the vulnerable sequence, one context observes the sender as still active and proceeds toward resetting or re-arming the timer, while another context changes the sender state, stops the associated kernel thread, and cleans up the timer and related object references. If the first context re-arms the timer after cleanup has invalidated the reference, the timer may later fire against freed kernel memory. The immediate visible outcome may be a kernel oops, panic, or node reboot; with sufficient control over timing and heap layout, the memory corruption could potentially be developed into more serious kernel compromise. There is no public exploit maturity indicated in the supplied data, and this is not currently known to be used in ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the batman-adv fix replacing the vulnerable timer cleanup sequence with timer_shutdown_sync(). No exact fixed package versions were provided in the input, so use the fixed kernel packages from the operating system vendor or upstream stable kernel branch for the affected distribution. Where immediate patching is not possible, mitigate by disabling or unloading the batman-adv module if it is not required, preventing automatic loading of the module, and restricting adjacent access to batman-adv mesh interfaces. For embedded or appliance platforms, obtain firmware or kernel updates from the vendor. Because this is kernel code, service-level restarts are not sufficient after patching; plan for a reboot into the fixed kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build that contains the batman-adv timer_shutdown_sync() change. Validate exposure by checking whether the batman-adv module is loaded, configured, or auto-loadable and whether mesh interfaces are active. On Linux systems, review outputs such as `uname -a`, package manager kernel version information, `lsmod | grep batman`, `modinfo batman_adv`, and network interface configuration for batman-adv use. After remediation, reboot into the fixed kernel and confirm the old vulnerable kernel is not running. If batman-adv is not required, confirm the module is unloaded and blocked from auto-loading.

Typical attack path

1. Identify a Linux system, router, appliance, or mesh node using the batman-adv kernel module.
2. Gain adjacent-network positioning where batman-adv traffic can be sent to or through the target.
3. Generate batman-adv tp_meter-related traffic to initiate sender state and timer activity.
4. Trigger or race ACK handling against sender shutdown/cleanup behavior.
5. Cause the vulnerable timer to be re-armed after the associated sender reference has been released.
6. Wait for the timer callback to execute against invalid memory, causing kernel crash or potential memory corruption.
7. Use the resulting denial of service or, if exploit reliability is achieved, attempt kernel-level control.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel and system logs rather than conventional application logs. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore artifacts, hypervisor reset logs, watchdog reboot records, and network telemetry from mesh interfaces. Search for kernel oops, panic, KASAN, UBSAN, slab corruption, use-after-free, timer callback, and batman-adv/tp_meter messages around unexpected reboots or node instability. Investigate repeated crashes on systems with the `batman_adv` module loaded, especially if preceded by unusual batman-adv mesh traffic or throughput-meter activity from adjacent peers. There are no known actor-specific or ransomware-specific indicators in the supplied data, so detection should focus on behavioral and forensic artifacts of kernel memory corruption in the affected code path.

• batman_adv
• batman-adv
• tp_meter
• batadv_tp_sender_cleanup
• batadv_tp_sender_shutdown
• batadv_tp_recv_ack
• batadv_tp_reset_sender_timer
• timer_shutdown_sync
• timer_delete_sync
• kernel BUG
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• general protection fault
• Oops:
• kernel panic
• slab-use-after-free
• use-after-free
• Unable to handle kernel NULL pointer dereference
• watchdog: BUG: soft lockup
• /sys/module/batman_adv
• /proc/modules
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching systems that load or depend on the batman-adv kernel module, especially routers, wireless mesh nodes, edge devices, embedded Linux systems, and network appliances.
• Inventory Linux assets for loaded or available batman-adv support using module, kernel package, and network interface telemetry.
• Apply vendor kernel updates that include the batman-adv tp_meter timer cleanup fix, then reboot into the fixed kernel.
• If batman-adv is not business-critical, unload and blacklist the module to reduce attack surface.
• Restrict mesh-network adjacency and management access so untrusted devices cannot send batman-adv traffic to vulnerable nodes.
• Monitor kernel logs for crashes, use-after-free reports, timer callback faults, and batman-adv-related oops messages, especially on mesh networking devices.
• Because EPSS is currently low and no KEV listing is present, prioritize based on actual module usage and network exposure rather than fleet-wide Linux presence alone.