The Microchip VCAP driver implements per‑instance locks that protect the VCAP data structures in software, but the underlying hardware – the shared Super VCAP block on sparx5 and lan969x chips – is accessed by all instances and shares cache and command registers. Because each instance uses a different lock, concurrent operations on distinct VCAP instances can race. When a rule dump read occurs in debugfs outside the normal rtnl lock, it mixes a read command with a cache read while another thread may be writing a rule via tc‑flower. The shared cache can be overwritten between these steps, leading to the writer committing incorrect data and corrupting the hardware rule table. Faulty data in the rule table causes misconfigured traffic scheduling and packet loss, effectively disrupting network services.

This flaw is present in Linux kernel builds that include the Microchip VCAP driver for sparx5 and lan969x platforms. Any system that enables the VCAP debugfs interface is also vulnerable, as the rule dump operation runs outside the protection of the standard network lock. No specific kernel version range is given; the fix is merged into the kernel mainline and applies to subsequent releases.

The race condition is triggered by concurrent administrative operations that exercise the VCAP API, such as adding or deleting traffic control rules for different VCAP instances. The likely attack vector is local privileged execution: an attacker with kernel‑mode access can load a module that uses the VCAP driver or run elevated network configuration commands to create simultaneous rule changes and reproduce the corruption. The EPSS score of < 1% indicates an extremely low probability of exploitation, and the flaw is not catalogued in the CISA KEV list. Nonetheless, the CVSS score of 7.8 reflects a high severity because the vulnerability can corrupt hardware configuration and lead to denial of network service; therefore prompt remediation is warranted.