CVE-2026-72340 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap: fix races on the shared Super VCAP block
The VCAP instances on a chip are not independent, yet they are locked independently. On sparx5 and lan969x the IS0 and IS2 instances are backed by the same Super VCAP hardware block and share its cache and command registers: every access drives the shared VCAP_SUPER_CTRL register and moves data through the shared cache registers.
Accessing one instance therefore races with accessing another. The per-instance admin->lock cannot prevent this, as each instance takes a different lock.
The locking issue is mostly disguised by the fact that the core usage of the vcap api runs under rtnl. However, the full rule dump in debugfs decodes rules straight from hardware (a READ command followed by a cache read) and runs outside rtnl, so it races a concurrent tc-flower rule write to another Super VCAP instance.
Besides corrupting the dump, the read repopulates the shared cache between the writers cache fill and its write command, so the writer commits the wrong data and corrupts the hardware entry.
Introduce vcap_lock() and vcap_unlock() helpers and route every rule lock site in the VCAP API and its debugfs code through them. Replace the per-instance admin->lock with a single mutex in struct vcap_control that serializes access to all instances. The helpers reach it through a new admin->vctrl back-pointer, and the clients initialise and destroy the control lock instead of a per-instance one.
No path holds more than one instance lock, so collapsing them onto a single mutex cannot self-deadlock.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described affects the Linux kernel's networking subsystem specifically within the Microchip VCAP (Virtual CAM) driver implementation. This issue stems from improper locking mechanisms that govern access to shared hardware resources across multiple VCAP instances. The VCAP subsystem provides virtual content addressable memory functionality for network packet classification and filtering operations, particularly on Microchip Sparx5 and Lan969x switch chips where multiple logical VCAP instances are mapped to a single physical Super VCAP hardware block.
The fundamental technical flaw lies in the design of locking mechanisms within the VCAP driver architecture. While individual VCAP instances maintain their own independent locks through admin->lock structures, the underlying hardware presents a shared resource model where multiple instances actually map to the same physical Super VCAP block with common cache and command registers. This architectural mismatch creates a race condition scenario where concurrent access to different VCAP instances can interfere with each other's operations because they share the same VCAP_SUPER_CTRL register and cache memory spaces. The per-instance locking mechanism fails to address this hardware-level sharing constraint, leading to data corruption and inconsistent state management.
The operational impact of this vulnerability manifests in multiple ways that affect both system stability and network functionality. The race conditions primarily occur during rule dump operations in debugfs which execute outside the protection of rtnl (route netlink) locks, while concurrent tc-flower rule modifications to other Super VCAP instances continue simultaneously. This creates a scenario where hardware rule dumps become corrupted due to interference from concurrent write operations. More critically, when a reader accesses shared cache registers during hardware rule decoding, it can inadvertently repopulate the cache between a writer's cache fill operation and its subsequent write command execution. This results in writers committing incorrect data to hardware entries, causing permanent corruption of network packet classification rules that can affect traffic handling and security policies.
The mitigation strategy addresses this through architectural redesign involving new locking helpers named vcap_lock() and vcap_unlock() that properly serialize access to all VCAP instances through a single mutex within the struct vcap_control structure. This approach eliminates the per-instance locking mechanism by introducing a centralized control lock that all VCAP API access points and debugfs code routes through. The solution employs a back-pointer relationship through admin->vctrl to reach the shared control lock, with clients responsible for initializing and destroying this single control lock rather than managing multiple instance-specific locks. This design ensures that no execution path holds more than one instance lock simultaneously, preventing potential deadlock scenarios while maintaining proper serialization of hardware access. The fix aligns with security best practices by ensuring atomic access to shared hardware resources and preventing race conditions that could lead to arbitrary code execution or privilege escalation through corrupted network filtering rules.
This vulnerability maps directly to CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and represents a classic case of improper locking in kernel subsystems. The issue demonstrates how hardware sharing models must be properly reflected in software locking designs, particularly in networking drivers where concurrent access patterns can lead to critical system instability. From an ATT&CK perspective, this vulnerability could potentially enable privilege escalation or denial of service through network traffic manipulation if exploited, though the primary impact remains data corruption and system instability rather than direct execution exploits. The fix represents a fundamental architectural improvement that aligns software locking with actual hardware constraints, reducing attack surface and improving overall system reliability in network packet processing operations.