Cloudanix VulnDB

CVE-2026-64092

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux mesh networking code can cause computers to become unstable or crash when certain network measurement features are used.

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

What it actually does

Race condition in batman-adv tp_meter receiver shutdown allows a reference count leak on tp_vars when timer_shutdown_sync and batadv_tp_stop_all race, preventing the final put and leaving a dangling reference that can lead to use-after-free or memory corruption on subsequent operations.

Why it matters to the business

Linux systems using the batman-adv mesh protocol may experience kernel instability, crashes, or denial of service after prolonged use of throughput metering, increasing operational downtime and requiring unplanned reboots or maintenance windows.

How an attack unfolds

A local attacker with access to a system running batman-adv initializes a tp_meter receiver, triggers concurrent shutdown paths via batadv_tp_stop_all and the receiver timer, and exploits the atomic coordination flaw so neither path releases the tp_vars reference, eventually causing a reference leak that manifests as a crash or memory corruption when the object is later accessed.

How to fix it

Upgrade the Linux kernel to a version containing the atomic receiving flag fix for batman-adv tp_meter; rebuild and deploy the patched kernel across all affected hosts; if immediate upgrade is not possible, disable batman-adv or tp_meter functionality until patched kernels are available.

How to confirm the fix worked

Confirm the running kernel contains the atomic receiving variable and atomic_xchg logic in batadv_tp_receiver_shutdown and batadv_tp_stop_all; inspect /proc/config.gz or kernel source for the fix; run regression tests exercising concurrent tp_meter start/stop sequences and verify no reference leaks occur via kmemleak or similar tools.

Typical attack path

  1. Obtain local access on a Linux host running the vulnerable batman-adv module
  2. Load or configure batman-adv and initiate a tp_meter session to allocate tp_vars
  3. Concurrently invoke batadv_tp_stop_all while the receiver shutdown timer is active or expired
  4. Trigger the flawed atomic_xchg path so the reference is never put
  5. Continue operations until the leaked reference leads to use-after-free or kernel panic

How to detect it

Review kernel logs for batman-adv reference count warnings or use-after-free oops traces involving tp_vars or tp_meter; correlate with processes exercising batadv_tp_stop_all or receiver timer paths; inspect for repeated module reloads or mesh interface restarts around crash times.

What your security team should do

  • Prioritize kernel upgrades on all systems exposing batman-adv interfaces within the next maintenance cycle
  • Audit configurations to identify hosts actively using batman-adv tp_meter and schedule targeted patching
  • Monitor upstream kernel changelogs for the exact commit introducing the receiving atomic variable

The record

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all() skips its batadv_tp_vars_put(), and batadv_tp_receiver_shutdown() fails to put its own reference as well. Fix this by introducing a new atomic variable receiving that is set to 1 when the receiver is initialized and cleared atomically with atomic_xchg() by whichever side claims it first. Only the side that observes the transition from 1 to 0 is responsible for releasing the tp_vars timer reference, eliminating the uncertainty.

Affected packages

Ecosystem Package Introduced Fixed