Look up another CVE · open CVE-2026-64095 in the interactive tracker
CVE-2026-64095
batman-adv: bla: avoid double decrement of bla.num_requests
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/batman-adv. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64095 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The bla.num_requests is increased when no request_sent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the request_sent is actually set to a specific state and the atomic_dec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently. At the same time, it is necessary to modify request_sent (state) and bla.num_requests atomically. Otherwise batadv_bla_send_request() might set request_sent to 1 and is interrupted. batadv_handle_announce() can then set request_sent back to 0 and decrement num_requests before batadv_bla_send_request() incremented it. The two operations must therefore be locked. And since state (request_sent) and wait_periods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.num_requests is touched by a parallel running context with a valid backbone_gw reference after batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/batman-adv/bridge_loop_avoidance.c
net/batman-adv/mesh-interface.c
net/batman-adv/types.h
- What this is
- BATMAN ADVANCEDMAINTAINERS section matched on net/batman-adv/ · b.a.t.m.a.n@lists.open-mesh.org · Maintained
- Kernel module
- batman_adv
Check it on the machine
grep -wE 'CONFIG_BATMAN_ADV|CONFIG_BATMAN_ADV_BLA' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w batman_advPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BATMAN_ADV, CONFIG_BATMAN_ADV_BLA
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.27%, higher than 17.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/batman-adv
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.5 | 5.10.259 | 1f013bc94154 |
| 3.5 | 5.15.210 | 5328b9596077 |
| 3.5 | 6.1.176 | 8ff9c59d1b7b |
| 3.5 | 6.6.143 | a9393751ecf7 |
| 3.5 | 6.12.93 | 461f1e3dfb88 |
| 3.5 | 6.18.34 | 45384612f296 |
| 3.5 | 7.0.11 | 65497ad155a3 |
| 3.5 | 7.1 | 83ab69bd12b8 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The vulnerable BLA ANNOUNCE handling runs in batadv_bla_tx() when BLA ARP claim frames reach the batman-adv interface from an attached LAN segment, which is the intended BLA deployment (multiple mesh gateways on one Ethernet). This requires same-segment L2 adjacency, not arbitrary Internet reachability.
- AC:LAttack complexity, low
- The TOCTOU race between request_sent checks and num_requests updates is attacker-influenceable by flooding crafted BLA ANNOUNCE frames with mismatched CRCs while concurrent periodic work and purge paths run. The attacker controls one side of the race via packet timing and volume.
- PR:NPrivileges required, none
- Exploitation requires only the ability to inject valid BLA protocol frames onto the shared LAN or mesh segment as a peer backbone gateway, not root, CAP_NET_ADMIN, or any local privileges on the victim system.
- UI:NUser interaction, none
- No victim user action is required; the bug is triggered automatically when the attacker sends BLA frames that are processed by the victim's bridge-loop-avoidance code.
- S:UScope, unchanged
- The impact is confined to incorrect BLA state and packet forwarding on the victim's batman-adv mesh node within the same kernel/network security boundary, with no VM escape or cross-authority boundary crossing.
- C:NConfidentiality impact, none
- The bug is an integer counter synchronization error with no out-of-bounds read, use-after-free, or other memory access that could disclose kernel data.
- I:LIntegrity impact, low
- A corrupted num_requests counter can prematurely clear the multicast gate and disable bridge-loop avoidance, allowing unintended broadcast forwarding and Ethernet bridge loops, but there is no kernel memory write or code-execution primitive.
- A:HAvailability impact, high
- Counter underflow leaves num_requests permanently non-zero, indefinitely blocking all multicast/broadcast mesh traffic, and the opposite race can trigger sustained broadcast storms via bridge loops, causing total loss of mesh/LAN availability.