CVE-2026-98432: Linux TCP Use-After-Free リスクとパッチ検証

CVE-2026-98432: Linux TCP Use-After-Free リスクとパッチ検証

CVE-2026-98432は、LinuxカーネルのIPv4 TCPハンドシェイクパスにおけるuse-after-freeの脆弱性です。この欠陥は、2つのプロセッサが関連するリクエストソケットとチャイルドソケットを操作する際に、両方が同じIPオプションオブジェクトを参照できる場合に発生します。一方のパスはそのオブジェクトを直ちに解放する可能性がありますが、RCUリーダーとしてのみ保護されているもう一方のパスはそれを使い続けることができます。その結果、ネットワークトラフィックから到達可能なコードに古いカーネルポインタが残ります。

簡潔な説明は、よくあるカーネルレースコンディションのように聞こえますが、公開されている証拠は慎重な解釈を要求します。CVEレコードはCVSS 3.1スコア9.8を持っており、これはネットワークから到達可能で、認証不要で、最悪の場合の機密性、完全性、可用性への影響が高いことを示しています。Red Hatの製品分析では、エクスプロイトを困難なレースコンディションとみなし、サポート製品における実際の結果をより保守的に評価しているため、スコアは低い5.9となっています。別途、AnthropicのFrontier Red Teamは、制御されたラボ環境で、MPTCPリスナーを持つLinuxサーバーに対して、動作するリモートルートコード実行チェーンを報告しました。その結果は、特定の設定下でのエクスプロイト可能性を示す深刻な証拠です。しかし、これはパッチが適用されていないすべてのLinuxサーバー、すべての通常のTCPリスナー、またはすべてのディストリビューションビルドが同じ方法で侵害される証拠ではありません。

防御者は、これらの記述を補完的なものとして扱うべきです。アップストリームのレコードは、危険なメモリライフタイムエラーとその理論上の最大影響を特定します。ディストリビューションのスコアは、ベンダーが出荷したコード、設定、緩和策、および予想されるエクスプロイト条件を記述します。研究によるエクスプロイトは、特定のターゲットを通過する具体的なパスを実証します。3つのうちどれも無視されるべきではなく、その範囲を超えて拡大解釈されるべきでもありません。

実際的な対応は直接的です：到達可能なLinux TCPサービスを特定し、実際に実行されているベンダーカーネルを判断し、ベンダー提供の修正済みビルドをインストールし、それに再起動し、実行中のカーネルに修正が含まれている証拠を保持してください。MPTCPリスナーを公開しているホストは、公開された研究が特にその環境を検証したため、即時の注意が必要です。インターネットに面したゲートウェイ、ロードバランサー、Kubernetesノード、VPNエンドポイント、リバースプロキシ、およびLinuxネットワーキングを使用するアプライアンスも、MPTCPを意図的に有効にしていない場合でも、迅速な棚卸しが必要です。

CVE-2026-98432について確認されている事実

権威ある技術的な説明は、LinuxカーネルのCVEプロセスとアップストリームのパッチから得られます。問題は、TCPリクエストソケットに関連付けられたIPv4オプションデータの所有権と再利用に関係しています。TCPハンドシェイクのサーバー側では、カーネルはまだ完全なチャイルドソケットになっていない接続を表すために、軽量なリクエストソケットを作成します。ハンドシェイクが進むと、tcp_v4_syn_recv_sock()はリクエストのireq_optポインタを新しいチャイルドソケットのinet_optに転送します。オブジェクトは複製されません。

同時に、別のCPUが同じリクエストに関連付けられた再送信されたSYNを処理する可能性があります。その2番目のパスは、tcp_check_req()を通じて別のSYN-ACKを送信できます。tcp_v4_send_synack()やinet_csk_route_req()などの関数は、RCU読み取り側クリティカルセクション内でリクエストのIPオプションを読み取ります。後続のヘルパー関数（ip_build_and_send_pkt()やip_options_build()など）は、オプションオブジェクトのフィールドを逆参照します。Debianのセキュリティトラッカーは、アップストリームの説明を再現し、問題を修正されたDebianカーネルパッケージにマッピングしています。

ライフタイムの不一致が根本的な問題です。読み取り側はRCUがオブジェクトを保護しているかのように動作しますが、デストラクタは通常のkfree()でそれを解放します。通常のkfree()は、既存のRCU読み取り側が完了するのを待たずに、割り当てを再利用可能にします。チャイルドソケットが破棄される際に再送信SYNパスがまだオプションを使用している場合、2番目のCPUはもはやそのオブジェクトに属さないメモリを読み取り続ける可能性があります。主なアップストリームの修正は、関連するデストラクタでの即時解放をkfree_rcu()に置き換えることで、RCUの猶予期間が経過するまで再利用を遅延させます。

この脆弱性には、関連するリクエストマイグレーションケースもあります。net.ipv4.tcp_migrate_req=1が有効になっている場合、またはBPF_SK_REUSEPORT_SELECT_OR_MIGRATEプログラムがリクエストマイグレーションを制御している場合、カーネルはリクエストソケットをクローンする可能性があります。古いリクエストとそのクローンは、一時的に同じオプションオブジェクトを共有する可能性があります。古いリクエストへの参照を保持しているCPUは、クローンが解放されている間もオブジェクトを使用できます。したがって、カーネルの説明はinet_sock_destruct()とtcp_v4_reqsk_destructor()の両方を変更して、RCU対応の再利用を使用するようにします。

最初の問題はIPv4チャイルドソケットパスに特有です。なぜなら、対応するIPv6関数はポインタを転送するのではなく、オプションを複製するからです。アップストリームのテキストでは、CALIPSOが存在する場合のipv6_optに関連するIPv6リクエストマイグレーションの懸念についても言及しており、その条件は別途処理されるとしています。この区別は重要です。「IPv6は影響を受けない」という記述は広すぎますが、主なIPv4所有権転送バグが通常のIPv6チャイルド作成パスには適用されないという記述は正確です。

パッチは、ipv4: free inet_opt and ireq_opt after an RCU grace period.というタイトルのコミットe3f33b0a1d89としてアップストリームにマージされました。UbuntuのCVEページは、同じ導入および修正コミットを特定し、多くのUbuntuカーネルフレーバーを個別に追跡しています。これは、一般的なカーネルバージョンチェックがディストリビューション固有のステータスに取って代わることができないという有用な証拠です。

確立されていない事実

ここで引用されている権威ある情報源は、インターネット全体での広範なエクスプロイトを確立していません。Anthropicは、研究者が脆弱性をリモートルートコマンド実行に変換できたことを、制御されたターゲットでMPTCPリスナーに対して確立しました。これはクラッシュのみの証明よりも強力であり、緊急度に影響を与えるべきです。しかし、これは脆弱なMPTCPサービスの普及率、普遍的な成功率、または同じエクスプロイトチェーンがカーネルビルド、CPUアーキテクチャ、アロケータ、ハードニングプロファイル、ネットワークパス全体で変更なく動作する証明を提供するものではありません。

公開されている資料は、大量のSYN再送信がエクスプロイトであると仮定することを正当化するものでもありません。再送信されたSYNパケットは、パケットロス、非対称ルーティング、過負荷のサービス、クライアントの再試行動作、およびミドルボックスのために自然に発生します。レースコンディションのエクスプロイトは異常なパターンを生成する可能性がありますが、それらのパターンは脆弱なホスト、関連するオプション、カーネルの症状、およびタイミングとの相関関係が必要です。ネットワークアラートは調査を優先できますが、カーネル内でuse-after-freeが発生したことを証明することはできません。

すべてのベンダーカーネルを正確にラベル付けする単一のアップストリームバージョン文字列は存在しません。エンタープライズディストリビューションは、古いバージョンのように見えるベースを維持しながら、セキュリティ修正をバックポートすることがよくあります。クラウドプロバイダーやアプライアンスベンダーは、独自のカーネルビルドを出荷する場合があります。アップストリームのリリースリストと比較するだけのスキャナーは、偽陽性および偽陰性の両方を生成する可能性があります。防御可能な結論は、ベンダーのアドバイザリ、パッケージの変更履歴、ビルドメタデータ、VEXステートメント、または関連する修正コミットがバックポートされたことの直接的な確認から得られます。

最後に、MPTCPを無効にしても、根本的なIPv4ライフタイムバグは解消されません。これは、公開された研究チェーンで使用された正確なリスナー設定を削除し、MPTCPが不要な場合に即時の露出を意味のある程度減らすことができます。アップストリームの技術的な説明は、通常のIPv4 TCPリクエストおよびチャイルドソケットパス、およびリクエストマイグレーションをカバーしています。パッチの展開が持続的な修正となります。

脆弱なTCPパスの仕組み

TCPサーバーは通常、SYNを受信し、SYN-ACKで応答し、最終的なACKを待ちます。カーネルは、攻撃者がリソースを安価に使い果たせる可能性があるため、最初のパケットで完全な接続済みソケットを割り当てることを避けます。代わりに、ハンドシェイクを検証して完了するのに十分な状態を格納するコンパクトなリクエストソケットを作成します。ACKが到着し、接続が受け入れられると、カーネルは完全なチャイルドソケットを作成し、選択された状態をそれに移動またはコピーします。

IPv4オプションは、その遷移を複雑にします。IPオプションは、ルーティングやパケット処理に影響を与えるメタデータを運ぶことができます。カーネルは受信した情報を解析し、後で応答を構築するための内部表現を格納します。影響を受けるパスでは、リクエストソケットのireq_optポインタがチャイルドソケットのinet_optポインタになります。この転送はコピーを回避しますが、1つの割り当てのライフタイムが2つのソケットオブジェクトの境界を越えることを意味します。

ハンドシェイク状態が完全に落ち着く前に、同じ接続タプルに対する2番目のSYNが到着する可能性があります。再送信はTCPの通常のプロセスです。カーネルは別のCPUでそのSYNを処理し、元のリクエストソケットを使用してSYN-ACKを構築する可能性があります。Linuxネットワーキングは高度に並列であるため、チャイルドソケットは、別のCPUがまだ応答を構築している間に、切断に向かって進む可能性があります。リクエストパスはRCU読み取りロックを取得し、読み取り側クリティカルセクションが終了するまでデータは有効でなければならないことを示します。

古いデストラクタの動作はこの期待に違反していました。チャイルドソケットは、解放全体を遅延させるSOCK_RCU_FREE動作を運んでおらず、inet_sock_destruct()はinet_optを直接解放していました。2番目のCPUはポインタを保持し、すでにアロケータに戻されたメモリからoptlenを読み取ることができました。後続の割り当ては、そのアドレスに無関係なデータを配置し、読み取り間の値を変更したり、後続のコードが攻撃者の影響を受けたコンテンツで操作できるようにしたりする可能性があります。use-after-freeバグは、即時の症状が解放された割り当てに取って代わるものに依存するため危険です。古いアクセスは古いバイトを読み取り、無害に見える場合があります。破損したメモリやマップされていないメモリに遭遇してクラッシュする可能性があります。新しいカーネルオブジェクトを読み取ってデータを開示する可能性があります。割り当てパターンとタイミングを十分に制御できれば、研究者は古い参照をより強力な読み取り、書き込み、または制御フロープリミティブに変えることができます。したがって、脆弱性クラスは、間欠的なハンドシェイク障害からサービス拒否、コード実行まで、さまざまな結果をサポートしますが、特定の結果は特定のターゲットに対して実証される必要があります。

リクエストマイグレーションバリアントは、異なるトポロジを通じて同じライフタイム原則に従います。Reuseportは複数のソケットがリスニングポートを共有することを可能にし、BPFはターゲットの選択に参加できます。リクエストマイグレーションは、リスナーの状態が変更されたときに保留中の接続を移動する可能性があります。カーネルはリクエスト状態をクローンし、2つのリクエストオブジェクトが同じオプション割り当てを参照するウィンドウを作成します。一方のオブジェクトでポインタをクリアしても、それを参照しているCPUは保護されません。もう一方のオブジェクトのデストラクタが共有割り当てを即座に解放すると、その読み取り側は古くなります。

パッチは、すべての操作を1つのグローバルロックの後ろにシリアライズしようとはしません。それはホットネットワークパスでのスケーラビリティを損なうでしょう。代わりに、それは読み取り側がすでに使用している同期モデルと再利用を一致させます。これはまさにRead-Copy Updateが解決するために設計された問題の種類です。

RCUが安全境界を変更する理由

Read-Copy Update（RCU）は、ライターが置き換えを公開し古いバージョンの解放を遅延させる間、非常に低いオーバーヘッドで共有データにアクセスすることを読み取り側に許可します。読み取り側はRCU読み取り側クリティカルセクションに入り、ポインタを取得し、オブジェクトを使用し、終了します。ライターはオブジェクトをデータ構造から削除して新しい読み取り側がそれを見つけられないようにすることができますが、メモリを再利用する前に猶予期間を待つ必要があります。猶予期間は、古いポインタを見た可能性のあるすべての読み取り側が完了したことを保証します。

LinuxカーネルのRCUドキュメントは、本質的な削除と再利用の分割を説明しています。削除は到達可能性を変更します。再利用はストレージをアロケータに戻します。これらの操作を混同することは、use-after-freeエラーの一般的な原因です。RCUロックは、任意のオブジェクトに参照カウントを配置するわけではなく、直接のkfree()を安全にするわけでもありません。対応するライターは、call_rcu()またはkfree_rcu()などのRCU対応メカニズムを使用する必要があります。

CVE-2026-98432では、読み取りパスはすでにRCUを使用しています。修正は、デストラクタがその契約を遵守するようにします。kfree_rcu()は、即座に解放するのではなく、猶予期間後にオブジェクトの解放をスケジュールします。SYN-ACKを構築しているCPUは、古いオプションオブジェクトの読み取りを完了できます。後続の読み取り側はそれ以上取得できなくなり、割り当ては既存の読み取り側がいなくなってからのみ再利用可能になります。

この設計は並列性を維持します。サーバーに再送信の処理を停止させたり、ハンドシェイク構築の周りに大きなロックを配置したり、読み取りごとにオプションオブジェクトをコピーしたりする必要はありません。セキュリティプロパティは狭く明確です：RCU読み取り側から見えるオブジェクトは、その読み取り側がアクセスする可能性のある期間、割り当てられたままです。

RCU修正は、パケットフィルタリングだけでは完全な解決策にならない理由も説明しています。メモリ安全性に関する欠陥は、オブジェクトのライフタイム管理にあります。フィルタリングはトリガーに到達しにくくする可能性があり、不要な機能を無効にするとパスのセットを減らすことができます。修正された再利用のみが、コードに到達するすべての正当なおよび悪意のあるパケットに対して不変性を回復します。

［画像: 再送信されたSYNが共有IPオプションを読み取っている間、別のパスがそれらを解放し、kfree_rcuが再利用を遅延させる様子を示す2CPUダイアグラム。］

9.8と5.9のスコアの調和

CVEレコードのCVSS 3.1ベクトルはAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hであり、9.8を生成します。このベクトルは、ネットワーク攻撃者がアカウントやユーザーインタラクションを必要とせず、攻撃の複雑さが低く、成功したエクスプロイトが機密性、完全性、可用性に高い影響を与える可能性があると仮定しています。これは、脆弱なアップストリームコンポーネントに対するCNAのベース特性を表しています。

Ubuntuは、その9.8の値を示していますが、CVSS 4.0の評価で攻撃要件が存在する8.3も公開しています。CVSS 4.0は、古いベクトルにきれいに収まらない前提条件を表すことができます。Ubuntuのページは、脆弱性を高優先度とラベル付けし、数値スコア全体を意思決定と見なすのではなく、パッケージごとの状態を公開しています。

Red Hatの5.9スコアは、異なる評価を反映しています。Red Hatは、その製品、バックポート、デフォルト設定、緩和策、および予想される結果のコンテキストで脆弱性を評価します。その分析では、レースコンディションは高複雑度と見なし、信頼性の高いセキュリティ影響はクラッシュまたはサービス拒否である可能性が高く、メモリ破損やより強力な結果は追加の条件に依存することを強調しています。ベンダーのスコアが低いからといって、アップストリームのバグが存在しないわけではありません。それは、ベンダーが出荷する製品に対してすべての最悪ケースのメトリックを受け入れていないことを意味します。

CVSSの不一致は、異なる形式で配布されるオープンソースコンポーネントでは一般的です。同じソース欠陥が2つの製品に存在する可能性がありますが、異なる設定を通じて公開されます。あるベンダーはデフォルトで機能を有効にするかもしれませんが、別のベンダーはそれを省略し、3番目のベンダーは到達可能性を変更する部分的なバックポートを持つかもしれません。カーネルハードニング、アロケータの動作、アーキテクチャ、コンパイラオプション、およびサービストポロジはすべて、脆弱なソース行を変更せずにエクスプロイト開発に影響を与える可能性があります。

運用上の優先順位付けでは、単一の普遍的なスコアよりも、短い環境固有の分析の方が役立ちます。

9.8スコアは、潜在的な上限を認識するのに役立ちます。5.9スコアは、Red Hatの製品固有のビューを理解するのに役立ちます。どちらの数字も、公開されたMPTCPターゲットがラボでエクスプロイトされたという事実を上回るべきではありません。また、ラボの結果を大規模なエクスプロイトの主張に拡大解釈するべきでもありません。防御者は、これらの区別を維持しながら緊急に行動できます。

AnthropicのMPTCP研究が証明すること

Anthropicの10月27日の研究投稿は、Multipath TCPリスナーを持つサーバーに対するリモートのゼロクリックLinuxカーネルエクスプロイトを説明しています。研究者によると、エクスプロイトはレースによって誘発されたuse-after-freeを2段階で使用しました。最初の段階でカーネルポインタを取得し、Kernel Address Space Layout Randomizationを回避しました。2番目の段階でメモリ破損を制御フローハイジャックに変換し、最終的に攻撃者が選択したコマンドをrootとして実行しました。

チームは、概念実証がカーネルポインタを明らかにするのに約48分、コマンド実行に到達するのにさらに5分かかったと報告しています。失敗した試みは、ホストをクラッシュさせることなくハンドシェイクを不完全なままにする可能性があり、繰り返し試行を可能にします。レースコンディションのエクスプロイトは、失敗が容易で再試行が豊富にある場合に実用的になるため、この動作は関連性があります。

この研究は、脆弱性がサービス拒否を超える可能性があるという信頼できる証拠です。また、防御者に対して、どの公開露出が最も高い優先度を持つべきかを示しています：脆弱なカーネル上のMPTCP対応リスナーへの信頼されていないネットワークアクセスです。公式のLinux MPTCPドキュメントは、Multipath TCPが既存のアプリケーションと互換性を保ちながら、接続が複数のサブフローを使用できるようにTCPをどのように拡張するかを説明しています。LinuxディストリビューションはMPTCPサポートを提供する場合がありますが、すべてのアプリケーションやサービスがそれを使用するわけではないため、管理者はパッケージの存在から露出を推測するのではなく、実行時の状態とリスナーを確認する必要があります。

公開された概要は、再利用可能なエクスプロイトレシピではありません。それは、ヒープの状態、タイミング、アドレス開示、および信頼性の高い制御を再現するために必要なターゲット固有の詳細を省略しています。責任ある防御には、本番システムでこれらの段階を再現する必要はありません。動作する研究チェーン、調整された開示、アップストリームの修正、および安定したバックポートの存在は、パッチを適用するための十分な証拠を提供します。

いくつかの境界は明確に保たれるべきです。研究ターゲットはMPTCPを使用しました。カーネルビルドは異なります。報告された時間は1つの実験結果であり、保証された最小または最大ではありません。ネットワーク遅延、CPU数、負荷、アロケータの動作、ハードニング、およびサービス実装はレースを変更する可能性があります。投稿は、すべてのディストリビューションでデフォルト設定の通常のTCPサービスが同等にエクスプロイト可能であるとは述べていません。

したがって、最も防御可能な表現は次のとおりです。「CVE-2026-98432はLinuxネットワーキングを通じてリモートで到達可能である。Anthropicは、制御された環境で脆弱なMPTCPリスナーに対して認証されていないルートコード実行を実証した。より広範なエクスプロイト可能性と信頼性はターゲットに依存する。」このステートメントは、緊急性と正確性の両方を維持します。

影響を受けるバージョンとベンダーのバックポート

脆弱な動作は、079096f103faコミットなど、古いアップストリームの変更によって導入されました。これにより、TCPおよびDCCPリクエストソケットがリスナーロックなしで確立されたハッシュテーブルにインストールできるようになり、リクエストマイグレーションに関連する別の変更も行われました。影響を受ける履歴は多くのメンテナンスブランチにまたがっているため、Linux CVEレコードは単一の単純な脆弱範囲ではなく、ブランチ固有の修正を列挙しています。

アップストリームの安定版修正は、メンテナンスライン全体で発行されました。公開されているレコードで特定された最初の修正リリースには、5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、およびメインライン修正を含む7.3開発ラインが含まれます。これらの番号は、アップストリームカーネルには役立ちます。ベンダーが修正を低いベース番号のビルドにバックポートしたり、追加のリビジョン識別子を持つブランチを維持したりする可能性があるため、ベンダーパッケージの普遍的なルールとして使用してはなりません。

例えば、Debianのトラッカーは、Bookwormの6.1.190-1セキュリティパッケージとTrixieの6.12.113-1パッケージを修正済みとしてマークしています。また、後続のスイートの修正済みビルドも記録しています。これらのパッケージバージョンは、Debianシステムにとって正しい証拠です。Ubuntuでは、セキュリティページに、ジェネリック、AWS、Azure、GCP、KVM、Oracle、OEM、低レイテンシ、リアルタイムなど、多くの個別のカーネルソースパッケージがリストされています。1つのフレーバーのステータスは、別のフレーバーが修正されていることを自動的に証明するものではありません。

Red Hatの顧客は、Red Hat CVEページと、正確なRHELまたはOpenShift製品に適用されるエラッタを使用する必要があります。エンタープライズカーネルは、セキュリティパッチを組み込みながら、意図的に安定したインターフェースとバージョンファミリーを維持します。バージョンのみのスキャナーがアップストリームの最初の修正バージョンを期待している場合、修正済みのRed Hatカーネルがフラグ付けされる可能性があります。逆に、アプライアンスで高いベースバージョンが見つかっても、ベンダーがすべての安定版パッチを含んでいることを証明するものではありません。

SUSEのCVEページ、Gentooのセキュリティアドバイザリ、クラウドプロバイダーの通知、およびアプライアンスベンダーの通知を、それぞれの製品について参照する必要があります。ベンダーが判断を公開していない場合は、VEXまたはサポートステートメントを要求して、脆弱なコードが存在するかどうか、およびどのビルドに修正が含まれているかを確認できます。

コンテナは特別な注意が必要です。コンテナは通常、ホストカーネルを共有します。アプリケーションイメージを更新しても、TCPトラフィックを処理するカーネルは置き換えられません。マネージドKubernetesの顧客は、ノードイメージの更新、ノードプールのロールアウト、またはプロバイダーのメンテナンスアクションが必要になる場合があります。セルフマネージドクラスターには、ホストパッケージの更新とノードの再起動が必要です。交換後、一般的な展開がフリート全体に到達したと仮定するのではなく、すべてのノードを確認してください。

ライブパッチングはこの変更をカバーする場合があります。修正はネットワークデストラクタでのオブジェクト再利用に影響を与え、カバレッジはベンダーのライブパッチ実装とサポート決定に依存します。ライブパッチのステータスは、ベンダーがCVE-2026-98432に明示的に関連付けている場合にのみ有効と見なしてください。そのような確認がない場合は、修正済みカーネルをインストールして再起動してください。

変更ウィンドウの前に露出インベントリを構築する

適切なインベントリは、脆弱性の存在と攻撃の到達可能性を分離します。存在とは、実行中のカーネルに修正なしで影響を受けるコードが含まれているかどうかを問います。到達可能性とは、どの信頼されていないネットワークとサービスが関連するハンドシェイクパスを行使できるかを問います。両方が重要です。脆弱だが隔離されたラボホストは、計画された更新ウィンドウに従うことができますが、公開MPTCPサービスはキューの先頭に移動する必要があります。

TCPを直接Linuxで終端するシステムから始めます：リバースプロキシ、Webサーバー、APIゲートウェイ、イングレ スノード、VPNコンセントレータ、ロードバランサー、メールゲートウェイ、DNS-over-TCPサービス、SSHバ スチョン、データベースエンドポイント、およびカスタムデーモン。内部的にLinuxを識別するアプライアンスも含まれます。ハードウェアのように見えるエッジ製品でも、Linuxネットワークスタックを公開する可能性があります。外部接続を個別のデバイスが終端するかどうかを確認します。クラウドロードバランサーは、公開ハンドシェイクを吸収し、バックエンドへの2番目の接続を確立する場合があります。これにより、バックエンドカーネルへのインターネットからの直接的な到達可能性が低下する可能性がありますが、ロードバランサー自体および内部の信頼されていないクライアントはスコープ内に残ります。アプリケーションアーキテクチャ図がネットワーク終端を省略していることに依存するのではなく、実際の接続パスをアセットレコードに保持してください。

MPTCPの状態を確認します。適切なiproute2バージョンを持つシステムでは、ip mptcp endpoint showおよびip mptcp limits showで設定されたエンドポイントと制限を表示できます。利用可能な場合はsysctl net.mptcp.enabledを検査します。また、明示的にMPTCPソケットを作成するアプリケーションも特定します。グローバルな有効フラグだけではリスナーが存在することを証明しません。MPTCPアップストリームプロジェクトドキュメントは、テストと展開の参照を提供します。

リクエストマイグレーション設定をsysctl net.ipv4.tcp_migrate_reqで検査します。デフォルトと利用可能性は、カーネルと設定によって異なる場合があります。値1は、アップストリームで説明されているマイグレーションパスの関連性を高めます。リスニンググループにアタッチされたreuseport BPFプログラムを特定します。カーネルのSK_REUSEPORT BPFドキュメントは、プログラムタイプとソケット選択コンテキストを説明しています。これらの機能がないことは、主なIPv4パスが安全であることを証明しませんが、存在はテストとロールアウトの優先順位付けに役立ちます。

効果的なカーネル、パッケージ、起動済みイメージ、アーキテクチャ、およびベンダーを記録します。不変システムの場合は、ノードイメージまたはオペレーティングシステムリリースを記録します。アプライアンスの場合は、ファームウェアを記録します。マネージドサービスの場合は、プロバイダーのアドバイザリまたはサポートケースをキャプチャします。この証拠は、「Linux」とだけ書かれたスプレッドシートセルよりも役立ちます。

信頼境界をマッピングします。企業VLANからのみ到達可能なサービスでも、侵害されたラップトップ、ワークロード、またはパートナーから到達可能である可能性があります。Kubernetesノードポートは、イングレ ス設定とは異なる方法でリスナーを公開する可能性があります。IPv6を好む組織でも、デュアルスタックサービスと管理ネットワークはIPv4を有効にしたままにすることが多いため、IPv4の露出は依然として関連性があります。

エクスプロイトトラフィックなしで安全に検証する

本番環境での検証は、4つの質問に答える必要があります：実行中のカーネルは何か、それを供給したベンダーパッケージは何か、関連サービスは到達可能か、そしてベンダーはその正確なビルドが修正済みであると述べているか。レースに勝とうとしたり、カーネルメモリを破損させたり、アドレスを開示したり、概念実証を通じてコマンドを実行したりする必要はありません。

以下のコマンドは、管理下のシステムでローカルの事実を収集します。これらは脆弱性をトリガーしません。

uname -a
uname -r
cat /etc/os-release

# DebianおよびUbuntuパッケージの証拠
dpkg-query -W 'linux-image*' 2>/dev/null | sed -n '1,40p'

# RHELファミリーパッケージの証拠
rpm -q kernel kernel-core 2>/dev/null

# リスニングTCPソケット
ss -lntp

# MPTCPの状態（サポートされている場合）
sysctl net.mptcp.enabled 2>/dev/null
ip mptcp endpoint show 2>/dev/null
ip mptcp limits show 2>/dev/null

# リクエストマイグレーション設定（存在する場合）
sysctl net.ipv4.tcp_migrate_req 2>/dev/null

最小限必要な権限でコマンドを実行します。ss出力のプロセス名は、昇格された権限が必要な場合がありますが、リスナーのアドレスとポートはそれなしでも役立ちます。ホスト名、内部アドレス、またはサービス詳細が含まれている場合、完全なコマンド出力を公開チケットに貼り付けないでください。

次に、インストールされているパッケージをディストリビューションのアドバイザリと比較します。Debianでは、Debianトラッカーとインストールされているソースパッケージバージョンを使用します。Ubuntuでは、正確なカーネルフレーバーとリリース行を選択します。Red Hatでは、適用可能な製品ステータスとエラッタを使用します。ベンダーがバックポートを通じてビルドが修正済みであると述べている場合、一般的なアップストリーム比較よりもそのマッピングを受け入れます。

システムが更新されたカーネルで起動したことを確認します。パッケージのインストールは成功しても、実行中のカーネルは古いままの場合があります。再起動後、uname -rを予想されるインストール済みイメージと比較します。複数のブートエントリを持つシステムでは、ブートローダーが正しいイメージを選択したことを確認します。クラスターでは、すべてのノードから結果を収集します。

外部から到達可能なサービスについては、承認された評価ホストから、通常の接続試行、ロードバランサー設定、ファイアウォールポリシー、およびサービスディスカバリを使用して露出を検証します。不正なIPオプションやレースをトリガーする繰り返しのハンドシェイクを送信する必要はありません。標準的なTCP接続性があれば、信頼されていないトラフィックがホストに到達することを確認するのに十分です。

ラボチームがより深い保証を必要とする場合は、同じベンダーイメージを使用して使い捨て環境を構築し、その環境でのみカーネルサニタイザーを有効にし、ベンダー承認の回帰テストを実行します。KASANドキュメントは、カーネルのメモリエラー検出器を説明しています。KASANは開発と確認に価値がありますが、そのパフォーマンスコストと変更されたメモリレイアウトにより、本番環境での緩和策としては不向きであり、エクスプロイトタイミングを変更する可能性があります。

安全な検証レポートには、アセットID、ビジネスサービス、ネットワーク露出、MPTCPステータス、関連する場合のリクエストマイグレーションステータス、パッケージバージョン、実行中のカーネル、ベンダーアドバイザリURL、更新タイムスタンプ、再起動証拠、サービス正常性結果、および一時的な例外が含まれるべきです。その記録は、インシデント対応、監査、および後続のスキャンをサポートします。

検知とインシデント対応

メモリ破損のエクスプロイトが、単一の決定的なログ行を生成することはめったにありません。検知は、カーネルテレメトリ、ネットワーク動作、ホスト状態、および既知の脆弱なビルドを組み合わせるべきです。ip_options_build()、ip_build_and_send_pkt()、TCP SYN-ACK構築、またはソケット破棄に近いカーネルクラッシュは、即時のレビューに値します。inet_optまたはireq_optを含むuse-after-freeを特定したKASANレポートは、テストまたはデバッグ環境で特に重要です。

journalctl -k、dmesgアーカイブ、クラッシュダンプ、およびプラットフォームシリアルコンソールログを確認します。クラウドインスタンスは、ローカルログがフラッシュされる前に再起動する可能性があるため、集中化されたカーネルログとプロバイダーコンソール履歴が重要です。kdumpが展開されている場合は、vmcore、対応するアンストリップされたカーネルシンボル、パッケージメタデータ、およびブート設定を保持してください。インシデント計画の一部として証拠収集が必要な場合は、影響を受けたノードをすぐにリサイクルしないでください。

ネットワークテレメトリは、異常なオプションの組み合わせを持つ繰り返しの接続試行を送信したり、MPTCPリスナーに対して再試行を維持したりするクライアントを特定できます。まずベースラインを確認してください。モバイルネットワーク、損失の多いリンク、ヘルスチェック、およびSYNプロキシは、高い再送信カウントを生成する可能性があります。アラートには、宛先サービス、ソース分布、TCPオプションの概要、レート、期間、およびターゲットがその時点で脆弱であったかどうかを含めるべきです。

Anthropicによって説明されたエクスプロイトは、長い間隔にわたって繰り返し機会を必要としました。したがって、単一のソースまたは調整されたソースからの長期間のパターンは、小さなバーストよりも興味深い可能性があります。攻撃者は再試行を分散させることができ、通常のクライアントも長期間再試行できます。パターンをシグネチャではなく、調査コンテキストとして扱います。

エンドポイント検出エージェントは、カーネル内で開始および実行されるエクスプロイトに対して限定的な可視性しか持ちません。制御フローハイジャックが成功すると、後でユーザー空間プロセスを作成したり、資格情報を変更したりする可能性がありますが、通常の特権アクティビティに紛れ込むアクションを実行することもできます。予期しないrootプロセス、スタートアップ設定の変更、新しいネットワーク接続、モジュールアクティビティ、監査イベント、および整合性監視アラートを、カーネルおよびネットワークの証拠と相関させます。

エクスプロイトが疑われる場合は、証拠を保持するネットワーク制御を通じてホストを隔離し、組織のインシデントプロセスに従って揮発性状態をキャプチャし、ホストがアクセスできた資格情報をローテーションし、隣接するシステムを調査します。カーネルレベルの侵害は、ユーザー空間ログとエージェントの整合性に関する仮定を無効にします。侵害されたマシンに対する修正としてパッケージ更新を扱うのではなく、証拠収集後に信頼できるイメージから再構築します。

システムがMPTCPを公開していたかどうか、および疑わしいソースがそれに到達できたかどうかを確認します。イベント時刻周辺のファイアウォール、ロードバランサー、フロー、パケットキャプチャ、およびサービス設定を保持します。変更する前に、正確に起動したカーネルとパッケージを記録します。症状がクラッシュのみである場合は、偶発的なトリガーまたは無関係なバグの可能性を保持しながら、迅速にパッチを適用します。

パッチと緩和策戦略

推奨される修正は、RCU再利用修正を含むベンダーカーネルを適用し、その後そのカーネルで再起動することです。ディストリビューションの通常の更新メカニズムとそのアドバイザリを使用してください。カーネルベンダーまたは経験豊富なカーネルエンジニアリングチームが結果のビルドを所有していない限り、単一のメインラインコミットをエンタープライズカーネルにチェリーピックすることは避けてください。安定ブランチには関連するコンテキストが必要な場合があり、サポートされていないカスタムカーネルは将来のパッチとサポートのリスクを生じさせます。

フリートの場合、公開到達可能性、MPTCPの使用、リクエストマイグレーション、ビジネスクリティカリティ、テナント露出、およびベンダーサポートによってシステムをランク付けします。インターネットに面したノードと、大量の信頼されていないTCPを終端するインフラストラクチャから始めます。冗長なメンバーをローリングシーケンスでパッチ適用します：接続をドレインし、更新し、再起動し、実行中のカーネルを検証し、サービスチェックを実行し、ノードをローテーションに戻してから続行します。

即時の再起動が不可能な場合は、露出を減らします。組織が使用していない場合はMPTCPを無効にします。必要なソースとポートにインバウンドTCPを制限します。管理サービスを認証されたゲートウェイの後ろに移動します。未使用の公開リスナーを削除します。運用上安全な場合、アップストリームデバイスでレート制御またはSYNプロキシを適用します。これらの対策は機会を減らし、公開された研究パスを保護できますが、古いポインタを修正するものではありません。

net.ipv4.tcp_migrate_reqとreuseport BPFは、サービスオーナーと協力して評価してください。リクエストマイグレーションを無効にすると、影響を受けるパスの1つが減少する可能性がありますが、フェイルオーバー動作を変更する可能性があります。BPFプログラムを削除すると、トラフィック分散が変更される可能性があります。設定変更には機能テストとロールバック計画が必要です。

エッジでIPv4オプションをすべてブロックすると、オプションデータに依存するパスへの露出が減る可能性がありますが、それは不完全で潜在的に破壊的な制御です。一部のネットワークは特殊な動作にオプションを使用しており、フィルタとすべての脆弱なパスとの正確な関係を確立する必要があります。ミドルボックスは、単純なパケットフィルタリングとは異なる方法で接続を正規化または終端できます。そのような制御は、一時的なリスク削減としてのみ使用してください。

コンテナの再起動、アプリケーションの再デプロイ、またはユーザー空間ライブラリの更新に依存しないでください。脆弱なコードはホストカーネルで実行されます。Webアプリケーションファイアウォールが関連するIPおよびTCPハンドシェイク状態を認識または理解していると想定しないでください。TCP接続が確立された後に処理を開始するWAFは、脆弱な操作の下流にあります。

サポートされていないカーネルは、簡単な決定をもたらします。ワークロードをサポートされているビルドに移動するか、交換まで隔離します。ローカルでパッチが適用されたカーネルは、特殊な製品に適している場合がありますが、バックポートを検証し、ネットワーク動作をテストし、シンボルを維持し、出所を公開し、将来の修正を提供する担当者が必要です。ほとんどの組織にとって、ベンダーサポートのカーネルに移行する方が安全で迅速です。

Penligentは、セキュリティチームが公開サービス検出、設定証拠、および管理されたパッチウィンドウの周りの再テストを整理するのを支援することにより、承認された検証をサポートできます。このカーネル問題の目標は、本番環境でリモートルートチェーンを再現することではありません。それは、どの資産が到達可能であったか、どのベンダー修正を受け取ったか、そして修正後のサービスが正常に動作し続けたかを証明することです。

［画像: 露出を棚卸しし、ベンダーカーネルアドバイザリを確認し、更新し、再起動し、CVE-2026-98432修正を検証するための運用ワークフロー。］

修正が実際に機能したことを確認する

更新ジョブの成功は、修正されたホストと同じではありません。検証は再起動後に開始されます。uname -rでアクティブなカーネルを確認し、それをベンダーの修正済みパッケージにマッピングします。更新が期待されるブートパーティションにインストールされ、エラー後にブートローダーがフォールバックしなかったことを確認します。該当する場合は、セキュアブートポリシーがイメージを受け入れたことを確認します。

サービスの信頼境界の両側からサービスを検証します。内部ヘルスチェックはパスしても、パブリックリスナーが存在しない場合があります。パブリックチェックはパスしても、プライベートバックエンドパスが壊れている場合があります。通常のTCP接続確立、TLSネゴシエーション、プロトコルヘルス、および代表的なリクエストを実行します。MPTCPサービスについては、敵対的なタイミングやメモリ破損の試みなしに、組織の通常のMPTCP機能テストを使用します。

ロールアウトによって導入された警告についてカーネルログを確認します。ネットワーク修正は、ドライバ、オフロード、BPF、ロードバランシング、およびカスタムモジュールと相互作用する可能性があります。回帰は、無期限に脆弱なカーネルに戻ることを正当化しません。ベンダーのロールバックまたは交換ガイダンスに従い、一時的な露出削減を適用し、修正済みパッケージのエスカレーションを行います。

ベンダーがバックポートを理解しているスキャナーで再スキャンします。スキャナーがまだアセットをフラグ付けする場合、ベンダーアドバイザリ、インストールされているパッケージバージョン、実行中のカーネル証拠、および修正の出所を添付します。アップストリームバージョン比較に基づく広範な例外は、後で脆弱なノードを隠す可能性があるため、正確なビルドに対する正確な検出のみを抑制します。

Kubernetesおよび自動スケーリングフリートの場合、現在のインスタンスに加えてテンプレートを検証します。古いマシンイメージは、初期ロールアウト後に脆弱なノードを再作成する可能性があります。起動テンプレート、ノードイメージ、ゴールデンイメージ、リカバリメディア、および災害復旧定義を更新します。スケールアウトイベントをテストし、新しいノードが修正済みカーネルを起動することを確認します。

アプライアンスの場合、ファームウェアアップグレードが関連するカーネルビルドを変更したことを確認します。ベンダーの通知とファームウェアチェックサムを保持します。アプライアンスベンダーが修正を公開していない場合は、補償制御を文書化し、サポートステートメントを取得します。ファームウェアリリース日がアップストリームパッチの後だからといって、それが自動的に含まれていると仮定しないでください。

次のすべてが真である場合にのみ、修正項目を閉じます。

• アセットとその実際のTCP露出が記録されている。
• ベンダーがインストールされているビルドを修正済みまたは影響を受けないと特定している。
• 修正済みカーネルが実行されており、単にインストールされているだけではない。
• 必要な再起動またはベンダー承認のライブパッチアクティベーションが完了した。
• クリティカルサービスが変更後のテストに合格した。
• イメージ、テンプレート、および交換ノードソースが更新された。
• 一時的な緩和策と例外には、所有者と有効期限がある。
• 証拠がインシデント対応と監査のために保持されている。

一般的な評価の誤り

最初の誤りは、「Linux」を単一の製品として扱うことです。カーネルは、ディストリビューション、クラウドイメージ、組み込みファームウェア、マネージドノードイメージ、およびカスタムビルドを通じて出荷されます。それぞれが異なるバックポートを持つ可能性があります。正確な製品チャネルを使用してください。

2番目の誤りは、CVSSスコアとエクスプロイトの普及率を同等に扱うことです。9.8のベーススコアは、メトリックモデルの下での技術的な深刻度を表します。それは脆弱なホストの数を数えたり、アクティブなエクスプロイトを証明したりしません。5.9のベンダーのスコアは、ラボで成功したエクスプロイトを別の設定で無効にするものではありません。リスクは、深刻度、露出、証拠、アセット価値、および利用可能な制御を組み合わせたものです。

3番目の誤りは、Anthropicの結果を普遍的なものとして読むことです。この研究は、能力のあるチームがラボで脆弱なMPTCPリスナーをリモートでエクスプロイトできたことを証明しています。それは、すべてのTCPリスナーに対して同様の動作を確立するものではありません。MPTCPと露出したネットワーキングを優先するために使用しますが、サポートされていない主張を行うためではありません。

4番目の誤りは、IPv6が普遍的に安全であると宣言することです。主なチャイルドソケット転送の問題はIPv4固有ですが、アップストリームの説明ではCALIPSOを含むIPv6マイグレーションの懸念が別途指摘されています。デュアルスタックシステムもIPv4を公開し続けています。両方のプロトコルを評価し、後続のベンダー修正に従ってください。

5番目の誤りは、アプリケーションコンテナのみをスキャンすることです。コンテナイメージは、通常のモデルではアクティブなホストカーネルを運びません。ノードを棚卸ししてパッチを適用してください。サーバーレスおよびマネージドコンテナの顧客は、顧客がイメージを制御する場合でもプロバイダーがカーネルを制御するため、プロバイダーに相談する必要があります。

6番目の誤りは、公開エクスプロイトコードを本番テストとして実行しようとすることです。意図的にレースに勝つことは、マシンをクラッシュさせたり侵害したりする可能性があります。また、ベンダーがビルドが脆弱であることを確認した後、ビジネス上の価値はほとんどありません。安全な設定、パッケージ、露出、およびパッチ適用後のチェックは、脆弱性を武器化することなく、実行可能な証拠を提供します。

7番目の誤りは、再起動せずにチケットを閉じることです。ベンダーがサポートするライブパッチメカニズムがCVEをカバーしない限り、古いカーネルはシステムが新しいイメージを起動するまでアクティブなままです。常に実行結果を記録してください。

よくある質問

CVE-2026-98432は、すべてのLinuxサーバーでリモートrootアクセスを許可しますか？

• いいえ。このバグはネットワークから到達可能であり、制御された研究エクスプロイトは、脆弱なMPTCPリスナーに対してrootコマンド実行を達成しました。
• エクスプロイト可能性は、カーネルビルド、設定、アーキテクチャ、ハードニング、アロケータの動作、サービス露出、およびレースの信頼性に依存します。
• 影響を受け、到達可能なすべてのホストは、根本的な欠陥がカーネルメモリ破損であるため、パッチを適用する必要があります。

CVEレコードは9.8と表示されているのに、Red Hatは5.9と言うのはなぜですか？

• CVEスコアは、ネットワークアクセス、権限なし、インタラクションなし、および高い潜在的影響を持つ、アップストリームの最悪ケースのベースベクトルを表します。
• Red Hatは、その製品に対して問題をスコアリングし、レースの複雑さ、出荷された設定、および予想される実際の結果を考慮します。
• パッケージの状態についてはベンダーの評価を使用し、優先順位付けについてはより広範な証拠を使用してください。

IPv6は影響を受けますか？

• tcp_v4_syn_recv_sock()の主な問題は、通常のIPv6パスがオプションを複製するため、IPv4固有です。
• アップストリームの説明では、CALIPSOオプションを使用する場合の別のIPv6リクエストマイグレーションの懸念が指摘されています。
• 包括的な「IPv6安全」ラベルを適用するのではなく、ベンダーの完全なアドバイザリに従ってください。

MPTCPを無効にすると脆弱性は修正されますか？

• いいえ。これは、公開されたリモートコード実行デモンストレーションで使用された設定を削除し、MPTCPが使用されていない場合に即時のリスクを軽減できます。
• 根本的なライフタイムエラーは、IPv4 TCPリクエストおよびチャイルドソケット処理にも関連しています。
• 修正済みベンダーカーネルをインストールしてください。

コンテナの再構築が必要ですか？

• 通常のコンテナモデルはホストカーネルを共有するため、ノードまたはホストがカーネル修正を受け取る必要があります。
• アプリケーションイメージを再構築するだけでは、問題は修正されません。
• 自動スケーリングが脆弱なホストを再作成しないように、ノードテンプレートとマネージドクラスターイメージを更新してください。

バックポートされた修正はどのように検証すべきですか？

• 正確な製品とカーネルフレーバーについて、ディストリビューションのCVEページ、エラッタ、パッケージ変更履歴、またはVEXステートメントを使用してください。
• 修正済みパッケージがインストールされており、再起動後にuname -rが対応する実行中カーネルを示していることを確認してください。
• ベンダーがバックポートを文書化している場合に、アップストリームの最初の修正バージョンを要求しないでください。

防御者はエクスプロイトの概念実証を実行すべきですか？

• 本番環境でのエクスプロイトテストは不要であり、ホストをクラッシュさせたり侵害したりする可能性があります。
• カーネルの出所、露出、MPTCPおよびマイグレーション設定、ベンダーの状態、再起動完了、およびサービス正常性を検証してください。
• メモリ安全性に関する研究には、使い捨ての承認済みラボシステムを使用してください。

エクスプロイト試行を示唆する証拠は何ですか？

• IPv4オプション構築とソケット破棄に近い関連カーネルクラッシュまたはサニタイザ結果は、強力な技術的手がかりです。
• 脆弱なMPTCPリスナーに対する異常なハンドシェイク試行の繰り返しは、疑いを高める可能性がありますが、証明ではありません。
• ネットワーク動作を、カーネルログ、クラッシュダンプ、rootレベルのプロセス異常、および正確な脆弱ビルドと相関させます。

最終的な防御優先順位

CVE-2026-98432は、実際のカーネルオブジェクトライフタイム障害であり、単純なアップストリーム修正と実証された高影響の研究結果があります。そのリスクは、理論的なクラッシュに還元されるべきでも、すべてのLinuxサーバーがすでにリモートでエクスプロイト可能であるという主張に誇張されるべきでもありません。利用可能な証拠は、緊急かつターゲットを絞った行動を支持しています。

露出したMPTCPリスナーとインターネットに面したLinux TCP終端ポイントを優先してください。汎用バージョンマッチングではなく、ベンダーパッケージデータを使用してください。修正済みカーネルを適用し、再起動し、サービス操作を検証し、ノードとアプライアンスのテンプレートを更新し、実行中の修正の証拠を保持してください。変更ウィンドウがすぐに開けない場合は、未使用のMPTCPを無効にし、TCP露出を狭め、更新をスケジュールしながら、関連するカーネルとハンドシェイク動作を監視してください。

最も重要な技術的教訓は、このCVEよりも広範です：RCU保護は、読み取り側と再利用側の間の契約です。読み取りロックは、ライターがオブジェクトを直接アロケータに戻した場合、それを保護できません。パッチは、共有IPオプションを解放する前に読み取り側を待つことで、その契約を回復します。検証は、運用上の契約も回復する必要があります：組織は、どのホストが公開されていたか、どの修正コードを実行しているか、そして修正後にサービスが正常に動作し続けたかを知っている必要があります。

MPTCPおよびデュアルスタックサービスのための運用上の注意

MPTCPの棚卸しは、通常のTCPの棚卸しよりも目立たないことが多いです。なぜなら、管理者はカーネルがプロトコルをサポートしていることを知っていても、どのアプリケーションがMPTCPソケットをバインドしているかを知らない可能性があるからです。オペレーティングシステムのレイヤーから始め、次にサービスオーナーに、明示的にMPTCPソケットを作成しているか、またはサブフローをネゴシエートするライブラリやプロキシに依存しているかを尋ねます。サービスユニット、コンテナ機能、ソケットアクティベーション、および展開設定を確認します。ホストレベルで有効になっているフラグは手がかりであり、完全なサービスマップではありません。逆に、MPTCPを使用できるアプリケーションは、ある環境では通常のTCPにフォールバックし、別の環境では積極的にMPTCPでリッスンする可能性があります。

各候補サービスについて、リスナーがバインドされているアドレスファミリとインターフェイスを文書化します。ワイルドカードアドレスにバインドされたリスナーは、そのサービス設定が示唆するよりも多くのインターフェイスから到達可能である可能性があります。ホストファイアウォールルール、クラウドセキュリティグループ、ネットワークポリシー、およびアップストリームロードバランサーの動作はすべて貢献します。有用な記録は、信頼されていないクライアントがホストのTCPスタックにパスを完了できるかどうか、プロキシがクライアント接続を最初に終端するかどうか、および内部クライアントがスコープ内にあるかどうかを示します。これにより、単にパブリックDNSゾーンに存在しないサービスと、真に隔離されたサービスを区別することが可能になります。

デュアルスタック展開は、接続されたが別個の2つのパスとして評価されるべきです。IPv4およびIPv6ルート、リスナー、セキュリティグループ、および変換デバイスを個別に棚卸しします。アップストリームバグの主な所有権転送はIPv4コードにありますが、IPv6のみのパブリックイングレ スを持つホストでも、管理VLAN、クラスターオーバーレイ、ヘルスチェックネットワーク、またはローカルピアを通じてIPv4を公開する可能性があります。IPv6パケットは、脆弱なホストに到達する前に、別のIPv4接続に変換またはプロキシされる可能性もあります。ネットワークアーキテクチャであり、「IPv6のみ」のような製品ラベルではありません。カーネルが処理するものを決定します。

依存関係を特定する前に、フリート全体でプロトコルを無効にしないでください。MPTCPは、意図的なモビリティまたはパス回復力の設計の一部である可能性があります。性急な変更は、スループットの低下、フェイルオーバーの破損、または接続動作の変更を引き起こし、インシデントの診断をより困難にする可能性があります。MPTCPが使用されていない場合は、それを無効にすることが合理的な一時的な露出削減ですが、変更を記録し、サービスがそれに静かに依存していないことを確認してください。使用されている場合は、ベンダーカーネルのロールアウトを優先し、サービス目標と互換性のあるネットワーク制限を適用してください。

接続状態の周りのカーネル変更を計画する

ネットワークエンドポイントでのカーネルメンテナンスには、可用性の次元があります。再起動は、確立された接続を中断し、一部のアプライアンスで接続追跡状態をリセットし、ルーティングまたはオフロード動作を変更する可能性があります。ロードバランシングされたサービスを更新する前に、残りの正常なノードに十分な容量があることを確認してください。一度に1つのノードをドレインし、長期間のセッションが終了するか、合意されたタイムアウトに達するのを待ち、カーネルを更新し、再起動し、準備完了を確認してからローテーションに戻します。サービスが複数のパスにわたってMPTCPを使用している場合は、パスフェイルオーバー動作を変更テストに含めてください。

ステートフルファイアウォールおよびゲートウェイの場合、プラットフォームがローリングメンテナンス中に接続同期をどのように処理するかを確認してください。ノードはプロセスレベルでは正常である可能性がありますが、ルート、トンネル状態、またはコンントラック同期が収束していないため、トラフィックを受け入れる準備ができていない可能性があります。代表的なクライアントネットワークからのチェックを含めてください。ローカルヘルスエンドポイントだけではありません。ベンダーのサポートされているロールバックプロセスに従って前のイメージを利用可能にしてください。ただし、ロールバックがリスクレコードに記載されている一時的な露出制御をトリガーすることを確認してください。

カーネル拡張機能およびアウトオブツリーモジュールに合わせてパッチウィンドウを調整します。ストレージ、オブザーバビリティ、セキュリティ、およびネットワークエージェントは、新しいカーネルの起動を妨げたり、更新後に機能が失われたりする可能性があります。必要なモジュールに互換性のあるビルドと署名があることを確認してください。古いイメージへの起動失敗は、監視がパッケージマネージャーが正常に完了したことを示している場合でも、ホストを脆弱なままにする可能性があります。メンテナンス後、期待される修正済みビルドと実行中のカーネルの不一致をアラートします。

クラウドフリートの場合、インスタンスを交換する前にソースイメージを更新してください。実行中の仮想マシンの1回限りの再起動は、自動スケーリンググループ、インスタンステンプレート、リカバリ計画、またはマネージドノードプールが古いイメージを参照し続けている場合は不十分です。新しく起動された交換品を同じネットワークでテストし、ベンダーカーネルがアクティブであることを確認します。不変インフラストラクチャの場合、修正単位は個々のホストパッケージではなく、多くの場合イメージとロールアウトポリシーです。

Kubernetesの場合、ワークロードの中断予算と永続ストレージの制約に合わせてノードの退避を調整します。まずカナリアノードを更新し、CNIとサービスルーティングを検証してから、ゾーン全体に進みます。DaemonSetおよび特権エージェントは、カーネルバージョンとの互換性を確認する必要があります。コンテナがパッチ適用されたノードに再起動されるという事実は、すべてのレプリカが移動したことを証明しません。ノードレベルの証拠を収集し、各ワークロードを現在のノードに紐付けます。マネージドKubernetesの顧客は、プロバイダーがカーネルビルドを所有しているため、プロバイダーのノードイメージとメンテナンスガイダンスを使用する必要があります。

後で監査に耐える証拠を使用する

防御可能な修正レコードは、アドバイザリを特定のアーティファクトに紐付けます。ベンダーのCVEページまたはエラッタ、パッケージ名とリビジョン、ホストまたはイメージ識別子、更新後の起動時間、および実行中のカーネル文字列を保存します。ベンダーがソースパッケージの状態を公開している場合は、正確なカーネルフレーバーとリリースを含めます。製品がカスタムカーネルをバンドルしている場合は、アプライアンスファームウェアバージョンとベンダーステートメントを含めます。これにより、後でレビューする人が、一般的な「Linux更新済み」というメモがすべてのシステムをカバーしていたかどうかを推測する必要がなくなります。

SBOMを生成する組織の場合は、カーネルパッケージを影響を受けるアセットインベントリに接続し、利用可能な場合はVEXステートメントを保持します。VEXレコードは、製品が影響を受ける、影響を受けない、修正済み、または調査中であると述べ、その状態の根拠を説明できます。これは、アップストリームのCVEデータベースが広範な影響範囲を示している一方で、ディストリビューションが変更をバックポートしている場合に特に役立ちます。ステートメントは正確な製品リリースにスコープされたままであるべきです。証拠なしに異なるカーネルフレーバー全体で判断を再利用しないでください。

元のスキャン結果と更新後のスキャン結果を保持します。前後比較は、スキャナーがベンダーパッケージリビジョンを認識したことを示すことができますが、ベンダーマッピングに取って代わるべきではありません。更新後にスキャナーが引き続きCVEを報告する場合、検出が古いインベントリ結果、サポートされていないカーネル、再起動の欠落、またはバックポート処理による偽陽性であるかどうかを記録します。説明のない閉じられた検出は、防御が困難であり、誤って再オープンされやすいです。

所有者、ビジネス上の理由、補償制御、ターゲット日付、および明示的な再評価条件を持つ例外を追跡します。一時的に利用できないアプライアンスに対する例外は、受信できるネットワークパス、公開されるサービス、およびMPTCPがアクティブかどうかを特定する必要があります。例外を永続的なものにするのではなく、有効期限を設定します。ベンダーが修正を公開した場合、新しいエクスプロイト証拠が現れた場合、またはアプライアンスのネットワーク境界が変更された場合は、より早く再評価します。

セキュリティチームのための意思決定ガイド

セキュリティチームがCVEアラートを受信した場合、最初の決定は、脆弱性スキャナーがすでに検出結果を生成したかどうかではなく、組織が関連するカーネルを所有しているかどうかです。エンドポイント管理、クラウドインベントリ、仮想マシンイメージ、Kubernetesノードプール、ネットワークアプライアンス、および組み込み製品レコードをクエリします。カーネルパッケージとサポートされているOSファミリーを検索します。ソースリポジトリまたは実行時ラベルはシステムを見つけるのに役立ちますが、実際の実行中のフリートに対して確認してください。

2番目の決定は、どの資産が信頼されていないTCPトラフィックを受信できるかです。クラウドフローログ、ロードバランサー設定、ファイアウォールポリシー、サービスマップ、およびホストリスナーを組み合わせて使用します。マネージドプロキシによって終端されたトラフィックから直接インターネットトラフィックを区別します。侵害されたワークステーションやワークロードは信頼されていないソースになる可能性があるため、信頼された内部ネットワークを脅威モデルに含めます。コントロールプレーン専用のアプライアンスでも、顧客ネットワークから到達可能なデータプレーンインターフェイスを持つ場合があります。

3番目の決定は、いずれかの条件が優先度を上げるかどうかです。MPTCPリスナー、リクエストマイグレーション、reuseport BPF、公開露出、高価値ネットワークロール、または信頼できるホスト監視の欠如は、システムをキューの前方に移動させるべきです。これらの条件はエクスプロイトを証明するものではありません。それらは、既知の技術的パスに近い、または侵害された場合のビジネスインパクトが高い設定を特定します。

4番目の決定は、閉鎖をどのように検証するかです。サポートされている修正済みパッケージを特定し、それを展開し、それに再起動し、ネットワークサービスをテストし、最終状態をアドバイザリと比較します。計画されたメンテナンスチケットまたはダウンロードされたパッケージを閉鎖として受け入れないでください。実行時状態が証拠となります。パッチを適用できない場合は、時間制限付きの例外を記録し、組織がサポートされている修正を取得する間、到達可能なパスを削減します。

最後に、インシデント調査が必要かどうかを決定します。脆弱な公開MPTCPリスナーだけでは、緊急のパッチ適用が必要であり、それ自体では侵害を証明しません。関連するカーネル障害、疑わしい長期間の接続試行、説明のないrootアクティビティ、整合性の変更、または影響を受けるサービスに固有の信頼できる脅威インテリジェンスがある場合は、インシデント対応を追加します。パッチ管理とインシデント対応を連携させながらも別個に保つことで、過信とサポートされていない侵害宣言の両方を回避します。

リスクを正確に伝える方法

エグゼクティブへのアップデートには、影響を受けるアセット数、到達可能なサービス数、MPTCP露出、修正済みビルドの利用可能性、ロールアウトの進捗状況、および未解決の例外を含めるべきです。CVSS 9.8の数値を、製品固有の5.9評価と研究条件に言及せずに提示することは避けてください。その数値は有用な深刻度信号ですが、意思決定者は、自身の環境が実際に実行しているものと公開しているものを知る必要があります。

簡潔な技術的なステートメントは次のようになります。「LinuxのIPv4 TCPリクエストパスは、解放されたIPオプションメモリを使用できます。アップストリームの修正はRCUを通じて再利用を遅延させます。Anthropicは、制御されたラボで脆弱なMPTCPリスナーに対してリモートrootコード実行を実証しました。これは普遍的なエクスプロイト可能性を確立するものではありません。私たちはインターネットに面したMPTCP対応システムを最初にパッチ適用し、再起動後に実行中のベンダーカーネルを検証しています。」この表現は、知られていることの範囲を超えずに、結果、証拠、境界、および行動を伝えます。

顧客向けのコミュニケーションは、組織のインシデントおよび脆弱性開示ポリシーに従う必要があります。顧客システムがLinuxを実行しているという理由だけで、そのシステムが脆弱であると主張しないでください。プラットフォームまたはベンダーに正確なカーネルの状態を尋ね、修正済みビルドが利用可能かどうかを述べます。再起動のためにサービスの中断が必要な場合は、エクスプロイト証拠とは別にメンテナンスの影響を伝えます。

セキュリティチームは、不確実性も保持すべきです。ベンダーがカスタムイメージをまだ評価していない場合は、状態が調査中であり、いつレビューされるかを述べます。MPTCPリスナーが見つからない場合は、検査の証拠と時刻を記録します。システムがパッチ適用されているがスキャナーがバックポートを認識していない場合は、ベンダーの証拠を添付し、アセットデータが収束するまで検出をレビュー可能な状態に保ちます。

---