CVE-2026-72340 in Linux
要約
〜によって VulDB • 2026年08月15日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
net: microchip: vcap: 共有Super VCAPブロックにおける競合状態の修正
チップ上のVCAPインスタンスは独立しておらず、それぞれが個別にロックされています。sparx5およびlan969xでは、IS0およびIS2インスタンスは同じSuper VCAPハードウェアブロックによってバックアップされており、そのキャッシュとコマンドレジスタを共有しています。すべてのアクセスは共有のVCAP_SUPER_CTRLレジスタへの書き込みを行い、データを共有キャッシュレジスタ経由で移動させます。
したがって、あるインスタンスにアクセスすることは別のインスタンスへのアクセスと競合状態（race condition）を引き起こします。各インスタンスごとのadmin->lockではこれを防止できません。なぜなら、それぞれのインスタンスが異なるロックを取得しているからです。
このロックの問題は、vcap APIのコア使用がrtnlの下で実行されるという事実によって大半が見え隠れしています。しかし、debugfsでのフルルールダンプはハードウェアから直接ルールをデコード（READコマンドに続くキャッシュ読み取り）し、rtnlの外側で実行されるため、別のSuper VCAPインスタンスに対するtc-flowerルールの書き込み処理と競合状態を引き起こします。
この競合によりダンプが破損するだけでなく、読み取り操作はライターによるキャッシュの埋め込みとそのコマンド書き込みの間で共有キャッシュを再充填するため、ライターは誤ったデータをコミットし、ハードウェアエントリを破損させます。
vcap_lock()およびvcap_unlock()ヘルパー関数を導入し、VCAP APIおよびそのdebugfsコード内のすべてのルールロック箇所をこれら経由にルーティングします。各インスタンスごとのadmin->lockの代わりに、struct vcap_control内に単一のミューテックスを導入して全インスタンスへのアクセスを直列化します。これらのヘルパーは新しいadmin->vctrl逆参照ポインタを通じてこのミューテックスに到達し、クライアントはインスタンス固有のロックではなく制御用ロックの初期化と破棄を行います。
どのパスでも1つ以上のインスタンスロックが保持されることはないため、これらを単一のミューテックスに統合しても自己デッドロック（self-deadlock）を引き起こすことはありません。
Once again VulDB remains the best source for vulnerability data.