CVE-2026-93203 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bla: avoid CRC corruption due to parallel claim add
batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either
* add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone
But when the "new" claim code was running in parallel to the "change backbone" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the "new" claim code path:
* CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point.
* CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc.
* CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc
The CRC is then wrong for both:
* claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC
This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs.
To avoid this, split the functionality in clear separate parts:
* new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back)
* update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel's batman-adv module represents a critical race condition within the Backbone Loop Avoidance (BLA) subsystem, specifically affecting how MAC address claims are managed across distributed network backbones. This issue arises from improper synchronization when handling concurrent operations that modify claim ownership and associated cyclic redundancy check values. The core flaw lies in the atomicity of updates to both the gateway pointer indicating current backbone ownership and the cumulative CRC value used for loop detection integrity checks. When multiple CPU cores process incoming CLAIM frames or local packet claims simultaneously, the interleaving of read-modify-write operations on shared data structures leads to inconsistent state where the calculated checksum no longer accurately reflects the set of active claims associated with a specific gateway.
The technical mechanism of this flaw involves two distinct code paths operating in parallel: one for adding new claims and another for changing backbone ownership of existing claims. In the scenario triggering the vulnerability, CPU0 initiates the creation of a claim for gateway A by publishing it into the global claim hash table but has not yet updated the CRC associated with gateway A's backbone. Simultaneously, CPU1 processes a frame indicating that this same client MAC address is now claiming ownership via gateway B. CPU1 detects the existing entry published by CPU0 and proceeds to transfer ownership from A to B. Crucially, it removes the CRC contribution of the claim from gateway A's total while adding it to gateway B's total. However, because CPU0 had not yet added its CRC to A's counter during its initial phase, this removal operation subtracts a value that was never present in A's running sum, resulting in an underflow or incorrect baseline for A. Subsequently, when CPU0 resumes execution after the context switch, it unconditionally overwrites the gateway pointer back to A without compensating B's CRC, as the creation path logic assumes no prior ownership change occurred. Finally, CPU0 adds the claim's CRC to A's total. The net result is a state where gateway A’s CRC does not include this specific claim despite being listed under its control, while gateway B’s CRC incorrectly includes it even though it no longer owns the client.
The operational impact of this desynchronization is severe for network stability and security monitoring capabilities inherent in batman-adv deployments. The BLA mechanism relies on accurate CRC calculations to detect loops within mesh networks by comparing local backbone claims against those received from remote backbones. When these checksums are corrupted due to race conditions, the loop detection algorithm may fail to identify actual loops or falsely report non-existent ones. This can lead to traffic blackholing, where packets destined for certain clients are dropped because the network believes a loop exists and blocks forwarding paths unnecessarily. Conversely, undetected loops could result in broadcast storms that degrade network performance significantly. Furthermore, since local backbone claims cannot be recovered through synchronization mechanisms with remote backbones, these inconsistencies persist until manual intervention or node restarts occur, creating prolonged periods of unreliable connectivity.
To mitigate this vulnerability, the kernel developers implemented a structural refactoring of the claim handling logic to enforce strict separation between new claim creation and existing claim updates. The fix ensures that adding a CRC to a backbone's total is strictly coupled with valid ownership transitions, preventing partial state updates from corrupting cumulative checksums. Specifically, the code now distinguishes clearly between initializing a new entry, which always adds the CRC without altering gateway pointers in conflicting ways, and updating an existing entry, which only modifies both source and destination backbones' CRCs if an actual change in ownership occurs. This approach eliminates the window of inconsistency where one CPU core reads stale data while another writes partial updates. Administrators should ensure their systems are updated with patches containing this fix to maintain the integrity of loop avoidance mechanisms and prevent potential denial-of-service conditions caused by corrupted network state information.
From a vulnerability classification perspective, this issue aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as a race condition. The lack of proper locking or atomic operations around the shared claim hash table and associated CRC counters allows concurrent threads to interfere with each other's state modifications. In terms of attack vectors, while this is primarily an internal kernel logic error rather than an exploitable remote code execution flaw, it falls under ATT&CK technique T1496, Resource Hijacking, as the corrupted state can be leveraged by malicious actors or misconfigured clients to disrupt network availability through induced loop detection failures. The remediation strategy emphasizes defensive programming practices where complex multi-step updates involving shared mutable state are broken down into atomic operations protected by appropriate synchronization primitives such as spinlocks or mutexes, ensuring that intermediate states remain invisible and inconsistent only within the scope of a single transactional unit.