CVE-2026-72340

This CVE reveals a class of vulnerability that standard code review won't catch: a mismatch between the software model of independent hardware instances and the actual hardware topology. In the Microchip sparx5 and lan969x drivers, the software treats VCAP instances IS0 and IS2 as separate resources, each with its own mutex. The hardware team implemented them as a shared Super VCAP block with a common cache and command registers. The per-instance locking looked correct — no path holds more than one instance lock — so the code passed review. What nobody caught was that the hardware sharing made the locking model fundamentally broken. The race condition specifically involves the debugfs dump path. When you read VCAP rules via debugfs, the operation performs a READ command to hardware that repopulates the shared cache, followed by a cache read. That READ has a side effect: it overwrites the cache with hardware state. A concurrent tc-flower write that has already filled the cache with its own data, then issues a WRITE command, gets preempted by the debugfs READ — the cache gets stale data written back, and the WRITE commits corrupted entries to hardware. The rtnl lock happened to protect the normal tc-flower API path, so the bug only manifested through the debugfs interface. That's not a coding mistake — it's a systems design failure where the protection mechanism covered the primary path but not the diagnostic path that had hardware side effects. The fix is straightforward: collapse all VCAP instance locks onto a single mutex in struct vcap_control, eliminating any possibility of concurrent cache access. This removes the fiction of parallel access that was never safe to begin with. There is no real parallelism being sacrificed — concurrent IS0/IS2 writes to shared hardware were always silently corrupting data. The patch also adds the necessary back-pointer from struct vcap_admin to struct vcap_control. What you should check: if you maintain network switch drivers with multi-instance hardware blocks, audit whether those instances share any hardware resources (cache, command registers, interrupt controllers) that the locking model doesn't account for. Flag any debugfs or other diagnostic paths that touch hardware — a read operation with side effects is a race condition waiting to happen. The worst property of this bug class is the invisibility: corrupted VCAP entries don't crash, they silently misroute packets, bypass ACLs, or rewrite VLANs. On a production switch, you won't know your firewall rules are broken until someone notices traffic behaving unexpectedly.

Reviewed through automated stages and approved by a human before publication.