{"id":6967,"date":"2026-09-04T18:49:22","date_gmt":"2026-09-04T10:49:22","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-72340"},"modified":"2026-09-04T18:49:22","modified_gmt":"2026-09-04T10:49:22","slug":"cve-2026-72340","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-72340","title":{"rendered":"CVE-2026-72340 [HIGH] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nnet: microchip: vcap:"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>net: microchip: vcap: fix races on the shared Super VCAP block<\/p>\n<p>The VCAP instances on a chip are not independent, yet they are locked<br \/>\nindependently. On sparx5 and lan969x the IS0 and IS2 instances are<br \/>\nbacked by the same Super VCAP hardware block and share its cache and<br \/>\ncommand registers: every access drives the shared VCAP_SUPER_CTRL<br \/>\nregister and moves data through the shared cache registers.<\/p>\n<p>Accessing one instance therefore races with accessing another. The<br \/>\nper-instance admin-&gt;lock cannot prevent this, as each instance takes a<br \/>\ndifferent lock.<\/p>\n<p>The locking issue is mostly disguised by the fact that the core usage of<br \/>\nthe vcap api runs under rtnl. However, the full rule dump in debugfs<br \/>\ndecodes rules straight from hardware (a READ command followed by a cache<br \/>\nread) and runs outside rtnl, so it races a concurrent tc-flower rule<br \/>\nwrite to another Super VCAP instance.<\/p>\n<p>Besides corrupting the dump, the read repopulates the shared cache<br \/>\nbetween the writers cache fill and its write command, so the writer<br \/>\ncommits the wrong data and corrupts the hardware entry.<\/p>\n<p>Introduce vcap_lock() and vcap_unlock() helpers and route every rule<br \/>\nlock site in the VCAP API and its debugfs code through them. Replace the<br \/>\nper-instance admin-&gt;lock with a single mutex in struct vcap_control that<br \/>\nserializes access to all instances. The helpers reach it through a new<br \/>\nadmin-&gt;vctrl back-pointer, and the clients initialise and destroy the<br \/>\ncontrol lock instead of a per-instance one.<\/p>\n<p>No path holds more than one instance lock, so collapsing them onto a<br \/>\nsingle mutex cannot self-deadlock.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>net: microchip: vcap: fix races on the shared Super VCAP block<\/p>\n<p>The VCAP instances on a chip are not independent, yet they are lock<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-6967","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/6967","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}