CVE-2026-74686 in Linux
要約
〜によって VulDB • 2026年08月22日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
rqspinlock: デッドロック発生時にキューを保持する際にテール（tail）をリセットする
現在、デッドロックが検出された場合、rqspinlockにおけるウェイト待ちキューの破棄は抑制されています。デッドロックチェックは比較的頻繁に実行されます（AAの場合エントリ時、ABBAの場合1ms以内）。また、待機中のスレッドが必ずしもデッドロックを伴うロックシナリオに関与しているわけではありません。したがって、デッドロックを検出して退出する際にキューのフラッシュを行わず、他のウェイト待ちスレッドにロック獲得を試みる機会を与えることが有用です。
しかし、以前waitq_timeoutラベルで行ったのと同じロジックに従う必要があります。すなわち、テールをリセットし、それができない場合は次の待機中のスレッドに対して適切にシグナルを送ります。デッドロックの場合、このシグナルはMCSノードをアンロック済みとしてマークします。タイムアウトの場合はRES_TIMEOUT_VALをシグナルとして送ります。したがって、異なる点は伝播される値であり、これによってキューがアクティブなまま維持されるかフラッシュされるかが決定されます。
テールのリセットを行わずに次のウェイト待ちスレッドの到着を待つと、自分が最終的な待機中のスレッドとなり、次に続くスレッドが存在しないため、このパスで断続的なストール（停止）が発生する可能性があります。次のウェイト待ちスレッドが参加すれば、ブロック解除されます。理論的に次のウェイト待ちスレッドが決して参加しない場合、無限にストールするリスクがあります。
これはABBAデッドロックの場合のみ発生します。待機キューへのエントリはAAチェックによって保護されているためです。このシナリオに至る正確な実行シーケンスの例は以下の通りです：
CPU 0 がロックAを保持している。 CPU 1 がロックBを保持している。 CPU 2 がロックBを取得しようとし、Bに対する保留中の待機スレッドとなる。 CPU 0 がロックBを取得しようとする。Bにはlocked（ロック済み）およびpending（保留中）のビットが設定されているため、CPU 0 はキューに追加される。 CPU 1 がロックAを取得しようとする。 CPU 0 がABBAデッドロックを検出する。
CPU 0 でデッドロック検出が発生すると、node->next を埋めるためにキュー内の次の待機スレッドの到着を待ちますが、そのスレッドが到着するまで遅延が生じます。
これを修正するため、waitq_timeoutラベルに先行するデッドロックチェックのロジックを調整します。両方のケースに対するコードを統合し、「ret」を使用して伝播される値を区別するのが理にかなっていますが、このパッチでの差分ノイズ（diff noise）を避けるため、これは将来のリファクタリング作業として残しておきます。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.