Linux CVE-2026-98432の対処法 — MPTCPを切っても残るTCPの穴と修正状況

はじめに

Linux カーネルの IPv4 TCP に use-after-free の脆弱性 CVE-2026-98432 が見つかり、CVSS は 9.8 と評価されています。認証なしでリモートからコードを実行できる可能性があり、影響は Linux 4.4 以降と広範囲です。

「MPTCP を無効にすれば大丈夫」という理解も見かけますが、それでは足りません。この記事では、修正コミットをもとに原因を確認し、一時策の限界と、11 月 2 日時点の AWS・主要ディストリビューションの状況を整理します。

何が問題なのか

原因は TCP ハンドシェイク中の競合状態です。修正コミットと Zenn の解説によると、流れは次のとおりです。

SYN に付いていた IP オプションのコピーを、request socket が保持する
ある CPU が再送された SYN を処理し、そのオプションを読みながら SYNACK を組み立て始める
別の CPU が ACK を処理して子ソケットを作り、同じオプションをコピーせずに所有権だけ渡す
子ソケットがすぐ破棄されると、オプションは kfree() で即座に解放される
2 の CPU が解放済みのメモリを読み続ける

読む側は RCU の読み取りセクションで保護していたのに、解放する側が猶予期間を待っていませんでした。修正もそこだけで、inet_sock_destruct() と tcp_v4_reqsk_destructor() の kfree() を kfree_rcu() に替える 2 行の変更 です。

コミットが原因として挙げるのは 079096f（request socket を ehash に入れる変更）で、Zenn の解説によると 2015 年の変更で、Linux 4.4 から入っています。リスナーのロックなしで request socket を処理できるようになり、速くなった代わりに競合の余地が生まれました。もう 1 つの経路は net.ipv4.tcp_migrate_req=1 などによる request socket の移し替えで、こちらは既定で無効です。

この種の競合は通常、成立の難しさが攻撃の壁になります。ただし Anthropic の報告によると、競合に負けてもハンドシェイクが失敗するだけでシステムは落ちないため、攻撃者は成功するまで再試行できます。同社の PoC は、カーネルポインタの漏洩に 48 分、そこからコマンド実行まで 5 分でした。時間はかかっても、負けてもシステムが落ちないので再試行を続けられる点が厄介です。

評価は機関で分かれています。カーネル CNA は 9.8、Red Hat の CVE ページも 9.8（暫定値と明記）で、Ubuntu のページも 9.8 を表示しています（優先度は High）。SUSE は攻撃の複雑さを High と見て 8.1 としています。Atlas によると 10 月 31 日時点で CISA KEV には未掲載で、GitHub では少なくとも 6 件のリポジトリが race trigger か PoC を含むと称していますが、Atlas は検証していません。

MPTCP を無効にしても足りない理由

MPTCP が条件として語られるのは、Anthropic の PoC が「マルチパス TCP のリスナーを持つサーバー」を対象としているためです。一方、修正コミットの説明に MPTCP は出てきません。Go のセキュリティチームははっきりこう書いています。

the underlying bug is not specific to MPTCP.

Go 1.24 以降のプログラムは、Linux では既定で MPTCP のソケットで待ち受けます。自分で設定した覚えがなくても、Go 製のサーバーがあれば PoC の条件に当てはまることがあります。一方で、MPTCP のリスナーがないサーバーも安全とは言えません。Go チームは同じ投稿で、そうしたシステムも類似の攻撃を受ける可能性に触れています。

各一時策の位置づけは次のとおりです。

一時策	効果	限界
`net.mptcp.enabled=0`	PoC の前提を外す	AWS は「問題を解決するものではない」と明記。Atlas によるとネットワーク名前空間ごとの設定で、コンテナは別途必要
`GODEBUG=multipathtcp=0`	Go の既定を無効化	Go チームは「fragile」と評価。1 つでも漏れると残る
IP オプション付き TCP の破棄	脆弱な経路への到達を減らす	Red Hat は「完全には防げない」と明記

3 つ目は、原因が IP オプションの扱いにある点を突いたものです。Red Hat の速報は、nftables の input フックに ip protocol tcp ip hdrlength > 5 counter drop という規則を入れる手順を示しています。通常のアプリの通信には影響しないと見込む一方で、必要な処理を妨げる可能性にも触れています。Atlas によると、AlmaLinux は CIPSO ラベルを使うネットワークでは使わないよう勧めており、prerouting の規則でもブリッジ経由のコンテナ通信は素通りしたとのことです。

Zenn の解説によると、規則を入れる前に作られたオプションは消えません。同記事が引く登大遊氏の資料は、規則を永続化してから再起動することを勧めています。ただし公式の回避策ではなく、記事の著者も効果は試していないと書いています。Atlas の記事にある iptables 版は xt_u32 が必要で、RHEL 9・10 のカーネルにはありません。

修正状況（11 月 2 日時点）

環境	状況
上流	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 で修正
SUSE	SLES 16.0、15 SP4〜SP6 LTSS は修正版あり。一部製品は対応中
Amazon Linux	AL2、AL2023 ともに修正版あり
Ubuntu	修正版なし。26.10 / 26.04 / 24.04 / 22.04 は作業中、16.04〜20.04 は Vulnerable
RHEL 8 / 9 / 10	確認したページに修正版の記載なし。Red Hat は「expediting」としている

Ubuntu と Red Hat の速報は、どちらも 10 月 30 日更新のページの内容です。Red Hat は速報と CVE ページのみの確認で、個別のエラータまでは見ていません。動きが速いので、適用前に公式ページを確認してください。

AWS のセキュリティ速報（10 月 31 日更新）で、対応が必要なものをまとめます。

EC2 の Amazon Linux: AL2023 は sudo dnf update kernel --releasever=latest && sudo reboot、AL2 は sudo yum update kernel && sudo reboot
EC2 のその他の Linux、Lightsail: 各ディストリビューションの案内に従い、利用者が更新して再起動する
EKS: ノードの AMI を v20261031 以降に更新する（Auto Mode は自動で入れ替わる）
ECS on EC2: カーネルを更新して再起動するか、最新の AMI（20261031）のインスタンスに入れ替える
Fargate: 11 月 1 日 13:00 UTC（AWS の表記）より後に起動したタスクは修正済み。既存タスクは退役設定に従って入れ替わり、急ぐなら手動で入れ替える
RDS / Aurora: DB ポートをインターネットに公開しない。OS パッチは 11 月 3 日に提供予定
Redshift / Bottlerocket: 11 月 2 日から提供予定
Lambda: 影響なし
NLB の TCP リスナー、Global Accelerator、PrivateLink: Linux の利用者は、修正版が出たらプラットフォームのバージョンを更新する
WAF、ALB、CLB、NLB の TLS リスナー、CloudFront、API Gateway: 即時の対応は不要。背後のセルフマネージドインスタンスは 30 日以内に更新するよう推奨

エンジニアへの影響

まず確認するのは次の 3 つです。

uname -r                         # 動いているカーネルの版
ss -Mlnp                         # MPTCP で待ち受けているプロセス
sysctl net.ipv4.tcp_migrate_req  # 0 で移し替えの BPF もなければ 2 つ目の経路は閉じる

ss や sysctl の結果はネットワーク名前空間ごとに異なります。ホストだけでなく、コンテナで動かしているサーバーでも確認してください。

パッケージを更新しただけでは直りません。修正版のカーネルで起動して初めて有効になるので、uname -r で確かめます。AWS は、カーネル更新と再起動のほかにライブパッチの適用も解決策に挙げています。

優先すべきは、インターネットから直接 TCP を受けるホストです。私なら、修正版がある環境はすぐ更新と再起動を計画します。修正版がない Ubuntu・RHEL では、到達できる送信元を絞ったうえで IP オプションの破棄を検証して入れ、Go 製サーバーは ss -Mlnp の結果を見て MPTCP も切ります。どちらも修正版が出るまでのつなぎです。ロードバランサーの背後にあるホストは緊急度が下がりますが、AWS も 30 日以内の更新を求めています。

今回もう 1 つ考えたいのが、CVE の見方です。修正は 10 月中旬に stable へ入り、CVE も 10 月 15 日に公開されていました。一方で Atlas によると、Red Hat の Critical への引き上げは Anthropic の公表（10 月 27 日）より後の 10 月 30 日です。Zenn の解説によると RHEL の状態は「Fix deferred」から「Affected」へ変わっています。ディストリの初期評価だけを基準にしていると、悪用可能性が示された時点で急に優先度が変わります。インターネットに面したホストは、カーネルも定期的に更新して再起動できる運用にしておくほうが確実です。

まとめ

CVE-2026-98432 は、IPv4 TCP のハンドシェイク中に解放済みの IP オプションを読んでしまう競合で、修正は 2 行でも影響は Linux 4.4 以降に及びます。MPTCP の無効化や IP オプションの破棄は攻撃の条件を減らすだけで、根本的な対処はカーネルの更新と再起動（またはライブパッチ）です。Ubuntu と RHEL の修正版はまだ確認できていないので、公開ホストから優先して一時策を入れつつ、提供を待つことになります。

今日のその他のニュース

AI 学習の拒否を robots.txt で一括指定へ: User-Agent: __usage_ai-training の下に Disallow か Allow を書く方式で、クロール自体は禁止しません。OpenAI は数か月以内、Google は 2027 年を目指し、Microsoft は 2027 年 2 月から対応します。仕様は IETF の個人ドラフトです。（ITmedia）

Contact Form 7 に認証不要のファイルアップロードの脆弱性: 対象は 6.2〜6.2.3 で、6.2.4 で修正されました。6.2.4.1 以降が推奨で、WordPress 7.1 以上と PHP 8.3 以上が必要です。添付欄があるサイトは、アップロード先の一覧表示と直接閲覧ができないことも確認してください。（Rocket Boys）