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

  - net/rds:release_in_xmit() の wq_has_sleeper() を使用しますrelease_in_xmit() は、clear_bit_unlock() でRDS_IN_XMITをクリアしてから waitqueue_active() をチェックし、誰かがウェイクアップする必要があるかどうかを判断します。
    clear_bit_unlock() はリリース操作にすぎません。ビットがクリアされる前にクリティカルセクションを命令しますが、その後の待機キューヘッドの後続のプレーンロードは順序付けしません。waiter 側はミラー イメージを行います - 自身を待機キューに追加し、ビットをテストします。これが古典的なストアバッファリングパターンです:解放しているCPUは待機キューを空として読み取ることができますが、待機CPUはまだビットをセットとして読み取るため、スリーパーは決して目覚めません。waiter は rds_conn_shutdown() と rds_tcp_reset_callbacks() であり、どちらもタイムアウトのない割り込み不可な wait_event() です。失われたウェイクアップにより、他の一部の送信者が再びビットをリリースするまで、シャットダウンワーカーを単一スレッドワークキューで絞り込みます。そして、障害が発生したために切断されている接続では、他の送信者が決して存在しない可能性があります。バリアはかつてそこにありました:release_in_xmit() は、コミット 1422f28826d2(rds:acquire/release_in_xmit() に取得/リリースの順序を導入する)まで、clear_bit() に続いて smp_mb__after_atomic() に続き、両方を clear_bit_unlock() に格納していました。これにより、ロックのハンドオフは強化されましたが、ウェイクアップチェックが依存する完全なバリアは警告なしでドロップされました。net/rds/ib_recv.c のリフィルに対応する release_refill() は、まさにこの理由から今でもその smp_mb__after_atomic() を持っています。waitqueue_active() の前に必要な完全なバリアが続く wq_has_sleeper() を使用します。(CVE-2026-98072)

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

検出

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

medium Nessus プラグイン ID 350476

バージョン 1.9