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

  - net/rds:rds_tcp_reset_callbacks() の RDS_IN_XMIT 取得 rds_tcp_reset_callbacks() は、パスの状態を RDS_CONN_RESETTING に設定して送信パスを静止し、下層のソケットをスワップして rds_send_path_reset() を呼び出す前に、RDS_IN_XMIT がクリアにサンプリングされるのを待ちます。ビットクリアのサンプリングは、それを所有することと同じではありません:rds_send_xmit()は、wait_event()が戻った直後にRDS_IN_XMITを再取得できます。ロックを取得した後の状態再チェックは、ストアバッファリングパターン(リセットターが状態を書き込み、ビットを読み取り、送信者がビットを書き込み、状態を読み取ります)であり、acquire_in_xmit()は取得操作にすぎません。したがって、弱い順序のアーキテクチャでは、両側が互いの書き込みを見逃す可能性があり、送信パスはその後、rds_send_path_reset()がcp_xmit_*状態を書き換えることと同時に実行されます。これはまさに上記のコメントでrds_send_されていますpath_reset() は呼び出し元に、防止するように指示します。代わりにロックを取り、ソケットのスワップとrds_send_path_reset()を挟んでロックし、最後にウェイクアップして解放します。待機の上で文書化したロック順序の制約は、依然として保持されます:ロックは lock_sock() の前に取得されるため、ソケットロックを保持している間、tcp_sendmsg() 内の送信者は決して待機できません。古いコードの 2 つの詳細が、同じ変更で消えます:- ロックが取得された後、t_sockは読み取り専用となりました。古いコードは待機する前にキャッシュしていました。rds_conn_shutdown()のティアダウンはそのソケットを解放してt_sockをクリアするため、待機の前にキャッシュされたポインターは、受け入れパスが再開されるまでに古くなっている可能性があります。RDS_IN_XMIT の下でそれを読み取ることで、次のパッチが用意する同じロックを破棄が所有されると、除外が完了します。
    それまでは、ティアダウンはビットのみをサンプリングし、2 つのパスは現在と同じように互いに露出したままです。- シリアル化が全く行われない rds_send_path_reset() と呼ばれる古い !osock の早期パス。現在は通常のパスと同様にロック下で実行されます。以前のパッチの条件付きRDS_CONN_RESETTING遷移は、いずれの方法でもソケットチェックの前に発生します:ソケットなしで見つかったパスがまだ接続中で(再接続ワーカーが t_conn_path_lock でブロックされている)、新しいソケットで正当に RERESET -> UP 状態になるか、その間に破棄されてドロップされています。古い待機ベースの不在を記述する関数内コメントは、ロックベースのものを説明するように書き直され、関数の上の古いブロックコメント(戻り値とt_sockライターの不完全なリストを記述していた)はリフレッシュされ、4つのライターすべて(接続、受け入れ、破棄、スワップパス)と、それぞれをシリアル化するものに名前を付けます。
    (CVE-2026-98070)

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

検出

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

high Nessus プラグイン ID 350536

バージョン 1.9