CVE-2026-74658 in Linux
要約
〜によって VulDB • 2026年08月22日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
futex: 堅牢なfutexのexit時の競合をさらに防止する
堅牢なfutexのアンロック処理では、FUTEX_WAITERSビットを含むfutex値全体に0が書き込まれ、1人の待機タスクがウェイクアップされます。このウェイクアップはワンショット通知であり、プロトコルはその受信者がfutexを取得して（残っている競合を認識した状態で）アンロックするか、再度スリープする前にFUTEX_WAITERSビットを設定し直すことを前提としています。もしウェイクアップされた待機タスクがそのいずれかの処理を行う前に終了した場合、カーネルは介入して次のタスクをウェイクアップする必要があります。
これはfutexプロトコルの既知の複雑な問題であり、以前にca16d5bee598（「futex: 堅牢なfutex exit時の競合防止」）コミットで部分的な修正が行われました。しかし、その修正では不十分です。
もしこの間に別のタスクが非競合状態の高速パスを通じてfutexを再取得した場合、通知は失われます：堅牢なexit処理はそのfutexが他のタスクによって所有されていることを確認して何もしず、新しい所有者はアンロック時にFUTEX_WAITERSビットを見ておらず誰もウェイクアップしません。残りの待機タスクは解放されたfutexの奥で永久にスリープします：
A が futex を保持し、B と C は FUTEX_WAIT でスリープ中 uval == A | FUTEX_WAITERS A の堅牢なアンロック: 0をストア, FUTEX_WAKE(1) で B をウェイクアップ uval == 0 D が高速パスで取得: cmpxchg(0 -> D) uval == D, FUTEX_WAITERS なし B はウェイクアップに応じる前に終了 B のexitウォーク、保留中の操作: owner D != B → アクションなし D のアンロック: FUTEX_WAITERS なし → ウェイクアップなし C は永久にスリープ
これは実装における明らかな欠陥であり、FUTEX_WAITERSビットの一貫性を保てていません。
この問題を回避するために、堅牢なリストのexit処理を強化し、futexワードが他のスレッドによって所有されているが FUTEX_WAITERS が設定されていない場合に追加のウェイクアップを行うようにします。
これは長年議論されてきた非競合状態での取得/解放と解放シーケンスの問題は修正しません（この問題は commit 3ca9595d9fb6（「futex: robust futex のアンロックサポート追加」）およびその後の変更で対処されていますが、上記で説明した問題までは考慮されていませんでした）。
競合状態にある堅牢なfutexのカーネル内アンロックに基づくより完全な解決策については、この変更に関連して議論されており、メインラインに組み込まれるのは遅かれ早かでしょう。
[ tglx: 変更ログを若干修正し、コーディングスタイルを整える ]
Be aware that VulDB is the high quality source for vulnerability data.