Linux batman-adv EUVD-2026-82311

Requires the target host to be running the Linux kernel batman-adv module with Bridge Loop Avoidance (BLA) enabled and participating in a mesh where the attacker can send CLAIM frames from a remote backbone gateway on the same L2 mesh (hence AV:A). Exploitation further depends on winning a genuine multi-CPU race between batadv_bla_add_claim()'s 'new claim' creation path and a concurrent 'change backbone' update for the same client address - a non-deterministic timing window that cannot be precisely steered. Limiting factors: batman-adv/BLA is not enabled by default on general-purpose systems, adjacency to the mesh is mandatory (no remote/internet reachability), no authentication bypass or memory-safety primitive is gained, and impact is confined to corrupted backbone CRC state (loop-avoidance integrity/availability) rather than host compromise.

This is a race-condition data-corruption bug in the Linux kernel's batman-adv bridge loop avoidance (BLA) subsystem, not an information-disclosure or code-execution flaw. The vendor CVSS 3.1 vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H (7.1) already sets C:N, confirming no confidentiality impact - which directly contradicts the 'Information Disclosure' tag. I partly disagree with the vendor scoring: the flaw is fundamentally a narrow timing window (CPU0 'new claim' path racing CPU1 'change backbone' path on the same client), so AC:L understates the difficulty and should be AC:H; a corrupted, never-recomputed backbone CRC degrades bridge-loop-avoidance correctness rather than crashing the host, so A:H is overstated (closer to A:L/I:L). No EPSS score, no CISA KEV entry, and no public exploit are present in the data - this is 'no public exploit identified at time of analysis.' The realistic priority is LOW: it requires an attacker (or peer) on the same batman-adv mesh emitting CLAIM frames while a local/remote claim add races, a condition that is not attacker-steerable with precision. AV:A is consistent with batman-adv being an L2 mesh protocol where CLAIM frames arrive from adjacent backbone gateways. Bottom line: high raw CVSS driven by A:H, but real-world risk is modest and non-targeted.

An attacker joined to the same batman-adv mesh network (adjacent/L2) as a target node repeatedly injects CLAIM frames for a client address that is also being claimed locally, hoping to interleave the 'new claim' and 'change backbone' code paths across two CPUs. If the race lands, the backbone CRC becomes permanently wrong and is never recomputed, degrading bridge-loop-avoidance integrity and potentially causing frame handling/loop-detection anomalies. No public proof-of-concept exists, and the timing window is not reliably attacker-controllable.