戻る

2026/11/04

CVE-2026-98432：Linux TCP の解放後使用、MPTCP 経由の AI によるリモート root、エンタープライズ Linux の防御策

Linux の IPv4 TCP 処理の競合、実証された MPTCP 経由のリモート root、RHEL・Ubuntu・Oracle Linux・Debian の修正と緩和策を解説します。

情報確認日：2026年11月3日 | LOGIQ 技術解説

2026年10月、Linux カーネルの IPv4 TCP 接続処理に存在する解放後使用（use-after-free、UAF）の脆弱性 CVE-2026-98432 が公表されました。Linux カーネルの CVE チームは10月15日に告知を出しています。10月27日には Anthropic が、未公開の社内研究用モデルによって、MPTCP（Multipath TCP）のリスナーを持つ Linux サーバーに対し、認証なしで root 権限のリモートコマンド実行を実証したと報告しました。重要なのは、この特定のエクスプロイト条件と、一般的な IPv4 TCP サービスに及ぶより広い脆弱性やサービス拒否（DoS）のリスクとを混同しないことです。

要点

  • この欠陥は通常の IPv4 TCP 接続要求処理における競合状態で、Linux 4.4 から存在します。バグ自体に MPTCP は必要ありません。
  • Anthropic のリモート root の実証は MPTCP リスナーを持つサーバーを対象としたものですが、その他の TCP サービスでもクラッシュ、サービス拒否、メモリ破損のおそれがあります。
  • Red Hat はこの問題を Critical（CVSS v3.1 9.8）と評価し、11月1日に RHEL 8、9、10 向けの修正済みカーネルをリリースしました。Ubuntu の修正は11月3日時点でまだ作業中でした。
  • ベンダーが承認した修正済みカーネルをインストールして再起動し、実行中のカーネルを確認してください。緩和策は露出を減らしますが、パッチの代わりにはなりません。

競合が発生する箇所

この問題は IPv4 TCP の3ウェイハンドシェイクに関係しています。リクエストソケットが保持する IP オプション（ireq->ireq_opt）は、tcp_v4_syn_recv_sock() の処理中に、コピーされないまま子ソケットの inet_opt に引き渡されることがあります。別の CPU が再送された SYN を処理して SYN/ACK を組み立てている間に子ソケットが破棄されると、使用中のオプションのメモリが解放される可能性があります。その後 ip_options_build() などの関数がアクセスすると、UAF が発生し得ます。

関連する競合は、net.ipv4.tcp_migrate_req=1 または BPF_SK_REUSEPORT_SELECT_OR_MIGRATE によるリクエストソケットの移行にも存在し、元のリクエストソケットと複製されたリクエストソケットの間でオプションのデータが共有されることがあります。脆弱な動作は Linux 4.4 にさかのぼりますが、実際の影響はバックポートも含め、ベンダーのカーネルごとに評価する必要があります。

アップストリームの修正コミット e3f33b0a1d89（”ipv4: free inet_opt and ireq_opt after an RCU grace period”）は、inet_sock_destruct() と tcp_v4_reqsk_destructor() での即時解放を、kfree_rcu() による RCU 遅延解放に変更します。Linux の CVE 告知では、カーネルバージョン 6.12.113、6.18.56、7.2.10、7.3-rc7 で修正されたとしています。最初の IPv6 の経路は同じ脆弱性ではありませんが、CALIPSO が関わる IPv6 の移行経路は別のパッチで対処されています。

実証されたリモート root と一般的な露出を混同しない

Anthropic の概念実証（PoC）は MPTCP リスナーを持つサーバーを対象とし、カーネルアドレスの情報漏えいと制御フローの乗っ取りを組み合わせたものです。報告された実験では、情報漏えいの取得に約48分、さらにコマンド実行の達成に5分を要しました。競合に負けてもハンドシェイクが失敗するだけでシステムはクラッシュしないため、攻撃者は再試行を続けられます。ただし、根本にある UAF は MPTCP 固有のコードではなく、通常の IPv4 TCP 接続要求処理にあります。

MPTCP を使わない一般的な TCP サービスすべてに対して、同じリモート root のエクスプロイト手法が実証されたわけではありません。とはいえ、MPTCP を無効にすればシステムが完全に安全になると考えるのも誤りです。Red Hat は、MPTCP は必須条件ではなく、MPTCP が無効（デフォルト）のシステムも影響を受けるとし、標準的な IPv4 TCP サービスにおける認証不要のリモートからのクラッシュ、サービス拒否、メモリ破損について警告しています。

主要ベンダーの評価：深刻度と修正状況

2026年11月3日時点の確認内容です。ベンダーのページは更新されるため、対応する前に必ず最新の情報を確認してください。

ベンダー深刻度修正状況
Red HatCritical、CVSS v3.1 9.811月1日に修正済みカーネルをリリース：RHEL 8（RHSA-2026:93414、NFV 向け kernel-rt は RHSA-2026:93415）、RHEL 9（RHSA-2026:93412）、RHEL 10（RHSA-2026:93413）。RHEL 9 の kernel-rt と OpenShift（RHCOS）は引き続き Affected。RHEL 6 と 7 は影響なし。
Ubuntu優先度 High、CVSS 9.826.10、26.04、24.04、22.04 の linux：Vulnerable（作業中）。20.04、18.04、16.04：Vulnerable。修正済みパッケージは未リリース。
Oracle LinuxImportant、暫定 CVSS 8.1OL7〜OL10 向けの UEK エラータ（ELSA-2026-500397、-500398、-500399）が10月16日付。RHCK エラータは11月2日付で OL8（ELSA-2026-93414）と OL10（ELSA-2026-93413）向け。OL9 向けの RHCK エラータはまだ掲載なし。
Debian（Security Tracker）bookworm 6.1.190-1（DLA-4841-1）、bookworm linux-6.12 6.12.113-1~deb12u1（DLA-4850-1）、trixie 6.12.113-1（DSA-6568-1）で修正。forky と sid も修正済み。

Red Hat（評価は10月30日に改訂、ブレティンの最終更新は11月2日）。公式の CVE ページでは、認証されていないリモートの攻撃者が通常の IPv4 TCP トラフィックを通じてカーネルメモリを破損させたりシステムをクラッシュさせたりできるとして、Critical（CVSS v3.1 9.8）と評価しています。RHEL 8、9、10 と OpenShift が影響ありとされ、RHEL 7 のカーネルは該当するコードが存在しないため影響なしとされています。11月1日以降、Red Hat の CVE データには修正済みカーネル kernel-4.18.0-553.182.1.el8_10（RHEL 8）、kernel-5.14.0-687.64.1.el9_8（RHEL 9）、kernel-6.12.0-211.72.1.el10_2（RHEL 10）が掲載されています。セキュリティブレティン RHSB-2026-016 はまだ「進行中」とされており、緩和手順はこちらで確認できます。5.9 や 8.1 といった二次情報源の古いスコアを、現在の Red Hat の評価として示さないでください。

Ubuntu（公式の表の最終更新は10月30日）。CVE としての CVSS は 9.8 で、Ubuntu 独自の優先度は High です。Ubuntu 26.10、26.04、24.04、22.04 の標準 linux パッケージは「Vulnerable, work in progress」とされ、予定されている修正バージョンがページに表示されています。20.04 は Vulnerable などとされています。AWS、Azure、HWE、RT などのカーネルフレーバーは個別に評価する必要があります。「work in progress」は修正がリリースされたことを意味しません。

Oracle Linux。Oracle 自身の評価は Important で、暫定 CVSS スコアは 8.1 です。OL7、OL8、OL9、OL10 向けの UEK エラータは10月16日付で、続いて11月2日に OL8 と OL10 向けの RHCK エラータが出ました。UEK での修正を RHCK やすべてのマイナーリリースに一般化してはいけません。インストールされているカーネルと正確なエラータを確認してください。

Debian。公式の Security Tracker では、bookworm-security 6.1.190-1 や trixie-security 6.12.113-1 などが修正済みとされています。インストール済みのパッケージバージョンと、再起動後に実行中のカーネルの両方を確認してください。

CVSS の結果は、ディストリビューション固有の構成や修正により CNA とベンダーの間で異なることがあり、評価が変わることもあります。確認した日付を必ず記録し、各公式情報源へのリンクを残してください。

防御策：緩和策はパッチの代わりにはならない

最優先は、ベンダーが承認した修正済みカーネルをインストールし、再起動後に実行中のバージョンを確認することです。修正がまだ提供されていない場合は、不要な公開 TCP サービスを閉じる、許可する送信元ネットワークを制限する、露出しているホストの監視を優先する、といった対応を検討してください。

Red Hat のブレティンでは、IPv4 ヘッダーに IP オプションを含む受信 IPv4 TCP パケットを破棄する nftables の緩和策が紹介されています。

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

これは完全な防御ではなく、IP オプションに依存するワークロードを妨げる可能性があるため、導入前に業務トラフィックへの影響を検証する必要があります。TCP ヘッダー内の通常の TCP オプションは引き続き許可されます。これは TCP Options フィールドをブロックするものではありません。OpenShift では、ノードレベルのルールはクラスターネットワーク内の Pod 間通信をフィルタリングしないため、ネットワーク境界でのフィルタリングが重要です。修正済みカーネルが稼働したら、このテーブルは削除してください。

ヒント：パッチ適用後は、uname -r の出力をベンダーのエラータに記載された修正バージョンと比較し、その出力を変更記録とともに保管してください。インストール済みでもまだ起動していないパッケージでは、脆弱性は解消されません。

Linux では、Go 1.24 以降の Go の net パッケージがリスナーで MPTCP をデフォルトで有効にします。Go チームは無効化の方法として GODEBUG=multipathtcp=0 を文書化しています（go.mod の godebug 行としても指定できます）。デフォルトを変更する提案はまだ議論中で、Go のメンテナーは本当の修正はパッチ適用済みのカーネルだとしています。この設定は Anthropic が実証した MPTCP に依存する攻撃経路への露出を減らせますが、カーネルの UAF そのものを修正するものではありません。MPTCP の利用状況はサービスごとに見直してください。

LOGIQ の視点

エンタープライズ Linux の保守では、公開された CVSS の数値や uname -r だけで安全性を判断することはできません。OS リリース、カーネルファミリー（たとえば UEK か RHCK か）、パッケージリリース、現在起動しているカーネル、ネットワークへの露出、MPTCP の設定、ベンダーのエラータ、再起動の証跡を合わせて評価してください。影響評価と検証から、展開、運用監視までの全体の流れを追跡することが大切です。

ベンダーの修正が保留中の場合は、一時的な緩和策による残存リスクを文書化し、パッチが提供された後に緩和策を再評価してください。AI によって脆弱性の実際の悪用可能性が高まるなか、エンタープライズの保守は、検知、検証、修正、そして正常な稼働の証跡まで、ライフサイクル全体をカバーする必要があります。

一次情報源と参考資料