Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - futex:堅牢な futex の終了競合をもう少し防ぎます 堅牢な futex のロック解除により、futex 値全体にわたって 0 が保存されます
    - ワイプFUTEX_WAITERS - 1 人のウェイターをウェイクアップします。そのウェイクアップはワンショット通知です:プロトコルは、futexを取得するか(残りの競合を認識しながら最終的にロック解除する)、または再びスリープする前にFUTEX_WAITERS再武装するかのいずれかを受信者に依存します。どちらかができるようになる前に、目覚めたウェイターが強制終了された場合、カーネルはジャンプして、次のタスクをウェイクアップする必要があります。これは、コミット ca16d5bee598 で以前に部分的に修正された futex プロトコルの既知の複雑さです(futex:堅牢な futex の終了競合を防止します)。残念ながら、この修正は不十分です。その間に、第 3 のタスクが競合していないファストパスを通じて futex を再取得すると、通知は失われます。堅牢な終了処理では、それが別のタスクによって所有されているとみなし、何もしないのに対して、新しい所有者には、ロック解除と誰も起動しないFUTEX_WAITERSは見られません。残りのウェイターは、フリーの futex の後ろで永遠に眠ります: A が futex を所有し、B と C が uval FUTEX_WAITスリープします == A |FUTEX_WAITERS 堅牢なロック解除:ストア 0、FUTEX_WAKE(1) ウェイク B uval == 0 D ファストパス 取得:cmpxchg(0 -> D) uval == D、ウェイクアップ B 出口ウォークで動作する前に FUTEX_WAITERS B が kill なし、op 保留中:所有者 D != B -> アクションなし D ロック解除:FUTEX_WAITERSなし -> ウェイクなし C が永遠にスリープしますこれは明らかに実装の欠点です、 これにより、FUTEX_WAITERSビットの整合性を維持できません。futex ワードが別のスレッドによって所有されているが、FUTEX_WAITERSが設定されていない場合に、追加のウェイクアップも実行するように、堅牢なリスト終了処理を強化することで、これを回避します。これは、競合しない引き継ぎ/解放シーケンスの問題を修正しません。この問題は、何年も前から議論され、コミット 3ca9595d9fb6(futex:堅牢な futex をロック解除するためのサポートを追加します)およびその後の変更で対処されていますが、上記の問題が考慮されていませんでした。競合する堅牢な futex のカーネル内アンロックに基づく、より完全なソリューションがこの変更のコンテキストで議論されており、遅かれ早かれメインラインで現れるはずです。[ tglx:変更ログをわずかに修正し、コーディングスタイルを修正 ](CVE-2026-74658)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-74658

medium Nessus プラグイン ID 338867

バージョン 1.3