【解説】CVE-2026-98432：LinuxカーネルIPv4 TCPの「10年潜伏したUAF」を正しく理解する

2026年10月31日 16:24

はじめに

2026年10月、LinuxカーネルにCVSSスコア9.8（Critical） の脆弱性が公開されました。CVE-2026-98432です。「リモートから認証なしでroot権限奪取」という刺激的な報道もあり、不安を感じた方も多いのではないでしょうか。

危険なターゲットは３つ

Linuxカーネル4.4以降を搭載し、IPv4でTCPサービスを外部公開しているサーバー（Debian/RHEL/Ubuntu/Amazon Linuxなど）
特に、アプリケーションが明示的にMPTCPリスナーを有効化しているサーバー（Go 1.24以降でビルドされたGo製サーバーアプリは意図せず該当する可能性あり）
修正カーネル未適用の環境（2026年10月31日時点でUbuntu 26.04やRHEL 8/9/10は修正パッケージ未提供）

ただ、実際に何が問題で、どこまで危険なのかは、報道だけでは見えにくい部分があります。この記事では、技術的な仕組みから実務的な対策まで、誤解しやすいポイントを整理しながら解説します。

1. 結論から：何が問題なのか

一言で言うと、「LinuxカーネルのIPv4 TCP実装に、2015年から潜伏していたUse-After-Free（UAF）脆弱性」 です。

重要なのは、これがMPTCPの脆弱性ではないという点です。MPTCPはあくまで「このバグに実用的に到達するための有力な経路」にすぎません。脆弱性の本体は、IPv4 TCPの接続確立処理におけるIPオプションのメモリ管理にあります。

2. 技術的な仕組み：なぜUAFが起きるのか

TCP接続確立とIPオプションの「所有権移転」

TCPの接続確立時、クライアントが`SYN`を送り、サーバーが`SYN-ACK`で応答します。このとき、`SYN`にIPv4オプション（Record RouteやTimestampなど）が付いていると、カーネルはそれを`SYN-ACK`でエコーバックするため、オプションのコピーをリクエストソケット（`ireq_opt`）に保持します。

問題は、接続確立時にあります。`tcp_v4_syn_recv_sock()`がリクエストソケットを完全なソケットに昇格させる際、オプションのコピーを作らず、同じメモリブロックへのポインタをそのまま子ソケットに渡します。つまり、2つのオブジェクトが1つのメモリ領域を共有する状態になるのです。

競合状態と即時解放

ここで、子ソケットが破棄されると、`inet_sock_destruct()`がそのメモリを通常の`kfree()`で即座に解放します。しかしLinuxカーネルはRCU（Read-Copy Update） という仕組みで並行処理を管理しており、本来は「全CPUが参照を終えるまで解放を待つ」必要があります。

この箇所ではRCUの猶予期間を待たずに解放してしまうため、別のCPUコアがSYN再送処理（`ip_options_build()`）で解放済みメモリを読みに行くと、UAFが成立します。

修正内容

アップストリームの修正コミット `e3f33b0a1d89` では、`kfree()`を**`kfree_rcu()`に置き換え**、RCUの猶予期間が終了するまで解放を遅延させるようにしました。

なお、IPv6はこの問題の影響を受けません。IPv6の実装（`tcp_v6_syn_recv_sock()`）では、IPv4と違ってオプションをコピーしているからです。

3. MPTCPは「脆弱性の原因」ではなく「攻撃経路」

ここが最も誤解されやすいポイントです。

MPTCP自体に欠陥があるわけではありません。 欠陥はIPv4 TCPスタックにあり、MPTCPはその脆弱なコードパスに実用的に到達するための入口として機能します。

なぜMPTCPが攻撃経路になるのか

AnthropicのFrontier Red Teamは、MPTCPリスナーを持つサーバーに対して、ゼロクリックでroot権限を奪取するエクスプロイトを実証しました。カーネルポインタのリークからrootコマンド実行まで、約53分で攻撃チェーンを完成させたとされています。

ただし、これはMPTCPリスナーが存在する特殊な条件下での成果です。通常のTCPでも理論上はトリガー可能ですが、実測では約4800万回の試行で2回しか成功しなかったというデータもあります。

MPTCPを使っているサーバーは少ない

MPTCPの公式FAQには「サーバーは通常、安定・高速・信頼性の高いネットワーク接続を持っているため、MPTCPから直接的な恩恵を受けることはほとんどない」と明記されています。2021年の調査では、Alexa上位ドメインでMPTCP対応は0.1%未満。2025年時点でも「ごく限定的にしか使われていない」と報じられています。

つまり、一般的なWebサーバーやSSHサーバーが自動的にMPTCPリスナーになるわけではなく、大半のサーバーはこの攻撃チェーンの前提を満たしていません。

4. CVSS 9.8と5.9、どちらを信じるべきか

同じ脆弱性に、カーネルCVEチームは9.8、Red Hatは5.9という異なるスコアを付けています。これは矛盾ではなく、評価の前提が違うだけです。

カーネルCVEチームは「理論上の最大影響」を評価しており、Red Hatは「実環境での悪用難易度と、実証された影響」を評価しています。Red Hatは、実証された影響をDoS（カーネルクラッシュ） と位置づけ、root権限奪取は「理論上の可能性」にとどまるとしています。

CVSS 9.8は「理論上の最大リスク」であり、「すべてのサーバーが直ちに危険」という意味ではありません。

5. 影響範囲と各ディストリビューションの対応状況

影響を受けるディストリビューション（2026年10月31日時点）

公開済みの修正カーネルバージョン

5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3-rc7

6. 自分の環境を確認する方法

カーネルバージョンの確認

uname -r

Debian/Ubuntu系では、パッケージバージョンも確認できます。

dpkg -l | grep linux-image

MPTCPリスナーの有無を確認（重要）

今回の攻撃チェーンの実用的な前提はMPTCPリスナーです。以下で確認できます。

# カーネルレベルでMPTCPが有効か
sysctl net.mptcp.enabled

# MPTCPリスナーが存在するか
ss -Ml

# MPTCP接続が存在するか
ss -M

# 設定済みMPTCPエンドポイント
ip mptcp endpoint show

`sysctl net.mptcp.enabled` が `1` でも、`ss -Ml` で何も表示されなければ、実際にMPTCPで待ち受けているアプリケーションは存在しません。今回の実証された攻撃チェーンの前提を満たしていないと判断できます。

7. 対策：優先順位をつけて実施する

最優先：修正カーネルへのアップデートと再起動

sudo apt update
sudo apt upgrade
sudo reboot

カーネルの修正は再起動するまで反映されません。GNOMEデスクトップ環境などで再起動が抑制される場合は、以下を使います。

sudo systemctl reboot -i

Debianはすでに修正済みです。UbuntuとRHELは修正パッケージの提供を待つ必要があります。

修正版が提供されるまでの緩和策

注意：MPTCPの無効化は緩和策であり、IPv4 TCPの根本バグは残ります。修正カーネルへのアップデートが本質的な解決です。

8. よくある誤解を整理

9. まとめ

CVE-2026-98432は、LinuxカーネルのIPv4 TCP実装に10年以上潜伏していたUAFです。CVSS 9.8という評価は「理論上の最大影響」を示すものであり、MPTCPリスナーを持つサーバーが最も実用的な攻撃対象になり得ます。

ただし、一般的なサーバーが自動的にMPTCPリスナーになるわけではなく、Debianはすでに修正済みです。修正カーネルが提供されたら速やかに適用し、再起動することが最も確実な防御策です。UbuntuやRHELで修正を待つ間は、MPTCPの無効化やIPv4オプション付きSYNのドロップといった緩和策を組み合わせてください。

「9.8だからといって、すべてのサーバーが直ちに危険」ではありません。しかし、「MPTCPを使っていないから安全」でもありません。正確な理解に基づいて、優先順位をつけた対策を進めましょう。