CVE-2026-98432とは - LinuxカーネルのIPv4 TCPの解放後使用と、ディストリビューションごとの対応

CVE-2026-98432は、LinuxカーネルがIPv4のTCP接続を受け付ける処理（3ウェイハンドシェイク）に見つかった、解放後使用（use-after-free）の脆弱性です。カーネルのCVEチームは2026年10月15日に公開し、CVSS 3.1で9.8（Critical）と評価しています。ネットワーク越しに、認証なしで、IPv4のTCPポートで待ち受けているサーバーへ届く経路です。

問題が入り込んだのはLinux 4.4で、10年近く前からある処理です。修正はカーネルの安定版の8つの系列に入っていますが、ディストリビューションによって修正版の提供状況が分かれています。この記事では、カーネルのCVEチームの記録と修正コミット、各ディストリビューションのセキュリティ情報をもとに、仕組みと対応を整理します（2026年11月2日時点）。

まず結論 - やること

• IPv4のTCPポートを外部に開けているLinuxサーバーは、すべて対象として考えます。Webサーバー、SSH、データベースなど、サービスの種類は関係ありません。
• ディストリビューションの修正済みカーネルに更新し、再起動します。カーネルの更新は、再起動するまで効きません。
• 修正版がまだ出ていない、または今すぐ再起動できない場合は、IPv4オプション付きのTCPパケットを落とすnftablesのルールで、既知の入り口をふさぎます（後述）。
• MPTCPを使っていないなら、net.mptcp.enabled=0で止めておくと、Anthropicが示した攻撃の経路は使えなくなります。ただし、バグはふつうのTCPの処理にあるので、これだけでは足りません。

CVE-2026-98432の概要

修正コミットの日付は2026年10月1日で、メインラインには7.3-rc7で入りました（DebianのSecurity Trackerの記載）。NVDの状態は「Received」で、NVD自身の評価はまだ付いていません。

タイムライン

脆弱性の仕組み

TCPの接続は、クライアントのSYN、サーバーのSYN-ACK、クライアントのACKの3つのパケットで始まります（TCPの3ウェイハンドシェイク）。今回の問題は、SYNにIPv4オプションが付いていたときの、その後始末にあります。

IPv4のヘッダーには、経路を記録するRecord Routeや、時刻を記録するTimestampといったオプションを付けられます。ふだんの通信ではまず使われませんが、カーネルはSYNに付いてきたオプションを、接続待ちの要求（リクエストソケット）に保存しておき、SYN-ACKを返すときに使います。

問題が起きる流れは次のとおりです。

1. 攻撃者が、IPv4オプション付きのSYNを送ります。カーネルはオプションをireq->ireq_optに保存します。
2. ハンドシェイクが終わると、tcp_v4_syn_recv_sock()がこのオプションを、コピーせずにそのまま新しい接続のソケット（newinet->inet_opt）へ引き渡します。
3. ちょうどそのとき、攻撃者が同じ要求に対するSYNを再送します。別のCPUが、再送されたSYNに応えてSYN-ACKを組み立て始め、同じオプションを読みます。
4. その間に攻撃者が接続を閉じると、新しいソケットが解放されます。このときinet_sock_destruct()が、オプションをふつうのkfree()で即座に解放してしまいます。
5. SYN-ACKを組み立てている側のip_options_build()は、すでに解放されたメモリを読み続けます。

SYN-ACKを組み立てる側は、RCU（読み手を止めずにデータを差し替える仕組み）の読み取りロックの中でオプションを読んでいました。ところが解放する側はRCUを使わず、読み手がいなくなるのを待たずに解放していました。修正は、解放をkfree_rcu()に変え、読んでいるCPUがいなくなってから解放するというものです。同じオプションを差し替えるほかの経路（setsockoptなど）は、もともとkfree_rcu()を使っていました。

この競合が起きうるようになったのは、Linux 4.4のコミット079096f103fa（tcp/dccp: install syn_recv requests into ehash table）からです。この変更で、接続待ちの要求をリスナーのロックなしで処理するようになり、SYN-ACKを組み立てている最中に新しいソケットが解放されるのを止めるものがなくなりました。

もう1つの経路: リクエストソケットの移行

CVEの説明には、似た問題がもう1つ書かれています。net.ipv4.tcp_migrate_req=1を設定しているか、BPFのBPF_SK_REUSEPORT_SELECT_OR_MIGRATEプログラムを使っている場合です。接続待ちの要求を別のリスナーへ移すとき、古い要求と複製が同じオプションを共有し、片方が解放されたあとも、もう片方を使っているCPUが読み続けることがあります。tcp_migrate_reqは既定では無効です。

IPv6は対象外

IPv6のTCPは、ハンドシェイクの終わりにオプションを複製しているため、主な問題の影響を受けません。IPv6には移行の経路で似た問題が残っていますが、対象はCALIPSO（IPv6のセキュリティラベル）を使った場合だけで、別のパッチで直すとされています。

カーネルのメモリ管理の考え方は、メモリアロケータの記事でも扱っています。

危険度

カーネルのCVEチームは、CVSSの各項目に理由を添えています。要点は次のとおりです。

Red Hatも9.8のCriticalと評価しています。理由として、特別な設定なしにふつうのIPv4 TCPの通信で届くことを挙げています。一方で、競合のタイミングに依存するため、任意のコードを確実に実行するにはヒープを細かく操る必要があるとも書いています。SUSEの評価は8.1（Important）です。

実際の攻撃の報告は、2026年11月2日時点で見当たりません。CISAの悪用が確認された脆弱性の一覧（KEV）にも載っていません（KEVのデータで確認）。

AnthropicのエクスプロイトとMPTCP

この脆弱性を報告したのは、AnthropicのXinyang Ge氏です（修正コミットのReported-by）。AlmaLinuxのブログによると、Anthropicは、自社のエクスプロイトがMPTCP（Multipath TCP）で待ち受けているLinuxサーバーに対して、リモートの攻撃者にrootとしてコマンドを実行させられると述べています。

報道では、次のような内容も伝えられています。

• エクスプロイトを作ったのは、公開されていないClaudeのモデル
• カーネルのポインタの漏えいから、rootでのコマンド実行まで約53分
• エクスプロイトのコード、試したカーネルの版や設定は公開していない
• MPTCPを止めるだけでは足りず、修正済みのカーネルへの更新が一番の対策

ただし、筆者はAnthropicの元の発表を確認できていません（未確認）。上の内容は、AlmaLinuxのブログと報道によるものです。

MPTCPは、1つの接続で複数の経路（Wi-Fiとモバイル回線など）を同時に使えるようにするTCPの拡張です。カーネルのnet.mptcp.enabledの既定値は1（有効）です（カーネルのドキュメント）が、アプリが明示的にMPTCPのソケットを作らない限り、MPTCPで待ち受けることはありません。AlmaLinuxは、MPTCPを既定で止めて出荷していると説明しています。

注意したいのはGoです。Go 1.24から、net.ListenConfigはMPTCPに対応したシステム（今はLinuxだけ）で、既定でMPTCPを使うようになりました（Go 1.24のリリースノート）。Go 1.24以降で作ったサーバーは、自分で設定していなくてもMPTCPで待ち受けている可能性があります。

いずれにしても、バグはふつうのIPv4 TCPの処理にあります。MPTCPの有無にかかわらず、修正済みのカーネルに更新する必要があります。

影響を受けるバージョンと修正版

カーネルの安定版では、次の版で直っています。

ディストリビューションのカーネルは、版の番号が上の表と一致しません。修正を取り込んだかどうかは、各ディストリビューションの情報で確かめます。

ディストリビューションごとの状況（2026年11月2日時点）

AlmaLinuxは、RHELの修正を待たずに、安定版カーネルの修正を自分たちで取り込んだと説明しています。10月30日のブログにある修正版は、AlmaLinux 8がkernel-4.18.0-553.180.2.el8_10、9がkernel-5.14.0-687.61.2.el9_8、10がkernel-6.12.0-211.69.2.el10_2です。

Ubuntuは、記事を書いた時点で修正版が出ていません。Ubuntuのサーバーでは、次の緩和策を先に入れておくのが現実的です。

構成ごとの対応方法

Debian、Ubuntu

sudo apt update
sudo apt full-upgrade
sudo reboot

Ubuntuは修正版が出たら、同じ手順で入ります。Debianでは、apt list --installed 'linux-image*'で入っている版を見て、上の表の版以上になっているかを確かめます。

RHEL、AlmaLinux、Rocky Linux など

sudo dnf update 'kernel*'
sudo reboot

AlmaLinuxでtestingの修正版を先に入れる場合は、ブログの手順どおり--enablerepo=almalinux-testingを付けて更新し、再起動のあとでtestingのリポジトリを無効に戻します。本番のマシンでtestingのリポジトリを有効のままにしないよう注意します。

クラウドとコンテナ

• コンテナはホストのカーネルを共有しているので、コンテナのイメージを更新しても直りません。直すのはホスト（Kubernetesならノード）のカーネルです。
• マネージドなKubernetesでは、修正済みのノードイメージに入れ替えます。
• ロードバランサーがTCPの接続を終端している構成では、外からのSYNは直接サーバーに届きません。ただし、ロードバランサーを通らない経路（管理用のSSHなど）が開いていれば、そこが入り口になります。

すぐに更新できないときの緩和策

IPv4オプション付きのTCPパケットを落とす

この脆弱性の入り口は、IPv4オプションを付けたTCPのSYNです。ふつうの通信でIPv4オプションはまず使われないため、オプション付きのTCPパケットを落としても、通常の接続には影響しません。AlmaLinuxが示しているnftablesのルールは次のとおりです。

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -300; policy accept;
    meta l4proto tcp ip hdrlength > 5 counter drop
  }
}
EOF

ip hdrlengthはIPv4ヘッダーの長さ（4バイト単位）で、オプションがなければ5です。5より大きいTCPパケットだけを落とします。priority -300で、接続の追跡（conntrack）より前に処理します。先頭のaddとdeleteは、同じテーブルが残っていても作り直せるようにするためのものです。

sudo nft list table ip cve_2026_98432

このルールはnftablesの設定ファイルに書いていないので、再起動すると消えます。再起動するときは修正済みのカーネルに入れ替わっているはずなので、そのまま消えてかまいません。修正版を入れたあとに外すときは、sudo nft delete table ip cve_2026_98432を実行します。

ネットワークの機器やクラウドのファイアウォールで、IPv4オプション付きのパケットを落とせる場合は、そちらでも同じ効果があります。

使っていないならMPTCPを止める

sysctl net.mptcp.enabled
sudo sysctl -w net.mptcp.enabled=0

再起動後も止めておくなら、/etc/sysctl.d/に設定ファイルを置きます。MPTCPを使うアプリがある場合は、止めると影響が出ます。繰り返しになりますが、これはAnthropicが示した経路を減らすもので、脆弱性そのものの対策ではありません。

影響を受けるか・更新できたかを確かめる

# 動いているカーネルの版（更新後は再起動してから見る）
uname -r
 
# IPv4で待ち受けているTCPのポート
ss -4ltn
 
# MPTCPで待ち受けているソケット
ss -Mltn
 
# IPv4オプション付きのパケットを落とすルールが効いているか
sudo nft list table ip cve_2026_98432

uname -rの版が、ディストリビューションの修正版になっているかを確かめます。パッケージを入れただけで再起動していないと、古いカーネルのまま動いています。

まとめ

• CVE-2026-98432は、IPv4オプション付きのSYNを入り口とする、LinuxカーネルのTCPの解放後使用です。Linux 4.4以降が対象で、CVSSは9.8です。
• 原因は、SYN-ACKを組み立てる側がRCUで読んでいるオプションを、ソケットを解放する側がRCUを待たずに解放していたことです。修正はkfree_rcu()への変更です。
• Anthropicは、MPTCPで待ち受けるサーバーでリモートからrootを取れると主張していますが、詳細は公開されていません。バグ自体はふつうのTCPにあるので、MPTCPを止めるだけでは足りません。
• 対策は、修正済みのカーネルへの更新と再起動です。Ubuntuなど修正版がまだないディストリビューションでは、IPv4オプション付きのTCPパケットを落とすnftablesのルールで入り口をふさいでおきます。

同じ年に見つかったLinuxカーネルの脆弱性としては、ローカルの権限昇格のBad epoll（CVE-2026-46242）も記事にしています。カーネルとユーザー空間の境目については、システムコールの記事も参考になります。

参考資料

• CVE-2026-98432（CVE.org）
• カーネルのCVEチームの告知（CVE-2026-98432.mbox）
• 修正コミット e3f33b0a1d89（GitHubのミラー）
• NVD - CVE-2026-98432
• Debian Security Tracker - CVE-2026-98432
• Ubuntu - CVE-2026-98432
• Red Hat - CVE-2026-98432
• AlmaLinux - CVE-2026-98432: Patched kernels available in testing
• Amazon Linux Security Center - CVE-2026-98432
• SUSE - CVE-2026-98432
• Go 1.24 Release Notes
• CISA Known Exploited Vulnerabilities Catalog