Linux カーネルの脆弱性（CVE-2026-98432）を初心者向けに解説｜TCP の競合状態と対応方法

2026年10月15日、Linux カーネルの開発プロジェクトは、IPv4 の TCP 通信を扱う部分に、メモリの解放済み領域を使ってしまう欠陥があるとして、CVE-2026-98432 を公表しました。管理番号をつける権限を持つ Linux カーネル側が、CVSS v3.1 で 9.8（Critical）と評価しています。

話題が一気に広がったのは、10月27日です。Anthropic が研究記事で、MPTCP（マルチパス TCP）の待ち受けを持つ Linux サーバーに対し、認証もユーザー操作もなく、外部から root 権限でコマンドを実行する概念実証を作ったと公表しました。同社の未公開 AI モデルが、脆弱性の発見から攻撃コードの作成までを行ったとされています。

直前に話題になった PHP の脆弱性 や Brotli の脆弱性 とは違い、今回の対象は OS の核にあたるカーネルです。PHP や Node.js を最新にしても、直りません。この記事では、どこに問題があり、どれほど危険で、何をすればよいのかを、順番に説明します。確認日は 2026年10月30日です。

OS の核の欠陥が、重く扱われる理由

最初に、なぜこの脆弱性が大きく扱われているのかを整理します。理由は 4 つあります。

理由 1: アプリの更新では直らない

カーネルは、OS の最も深い部分です。ネットワーク通信、メモリ、ファイルの管理を担当し、すべてのプログラムがその上で動きます。そのため、Web アプリや言語の実行環境を最新にしても、カーネル自体を更新しない限り、欠陥は残ります。

理由 2: ログイン不要で、ネットワークから届く

発端はネットワーク通信の処理です。攻撃には、認証もユーザー操作も要りません。外部から TCP の接続を開ける相手であれば、対象になりえます。

理由 3: 約 10 年前の変更から存在している

欠陥の原因となった変更は、Linux 4.4 に入ったものだと報告されています。Debian の情報では、原因の変更は 079096f103fa（SYN を受けた状態の要求を、ハッシュ表に入れる変更）です。これを含む幅広い版が、修正前の状態にあります。

理由 4: 古い版や、まだ修正の出ていない版がある

ディストリビューションごとに、修正の配布状況が異なります。確認日時点で、修正が間に合っていないものもあります。詳しくは、後の節で整理します。

悪用の状況はどうか

確認日時点で、CISA の KEV（悪用が確認された脆弱性）の一覧には載っていません。また、実際の攻撃を確認したという報告も、見つかっていません。Anthropic は攻撃コードを公開していません。

一方で、悪用されていない間に対処するのが、いちばん安く済みます。 発端の研究が「作れた」ことを示した以上、同じ道筋をたどる攻撃者が出てくる可能性を、否定できません。

先に結論: やることは「更新」と「再起動」

不安をあおるだけでは役に立たないので、先に結論を書きます。

1. 使っているカーネルの版を確認します。
2. ディストリビューションが出した修正版のカーネルへ更新します。
3. 更新したら、必ず再起動します。 再起動しないと、古いカーネルのまま動き続けます。
4. すぐに更新できない場合は、暫定対処で危険を下げます。

この流れを頭に置いて、以降を読み進めてください。

背景: TCP の接続が成立するまで

脆弱性を理解するために、TCP の接続の流れを簡単に説明します。専門的な話ですが、身近なたとえで十分に理解できます。

TCP の接続は、3 回のやりとりで成立します。電話をかけるときの流れと似ています。

サーバーは、最初の SYN を受けた時点では、まだ本物の接続を作りません。「接続の予約票」のようなもの（要求ソケット）を作って待ちます。3 回目の ACK が届いたら、予約票をもとに、本物の接続（子ソケット）を作ります。

IP オプションという付属情報

IPv4 の通信には、IP オプションという付属情報を付けられます。経路の記録や時刻の記録などです。予約票は、SYN に付いていたこのオプションを預かっています。

複数の CPU が同時に動く

最近のサーバーには、CPU が何個もあります。ある CPU が接続の準備を進めている間に、別の CPU が、同じ相手から届いた通信を処理することがあります。ここに、問題の種がありました。

問題の箇所: 「持ち主が代わったメモリ」を別の CPU が読む

次に、どこに欠陥があったのかを説明します。Debian のセキュリティ情報などによると、原因は次のとおりです。

接続が成立して、予約票から本物の接続が作られるとき、予約票が預かっていた IP オプションは、コピーされずに、子ソケットへ受け渡されます。 受け渡されたオプションの持ち主は、子ソケットに代わります。

ところが、このとき別の CPU が、同じ相手から再送された SYN を処理していることがあります。その CPU は、SYN+ACK の返事を組み立てるために、予約票のオプションを読みます（ip_options_build() という処理です）。

もし、その瞬間に子ソケットが先に片付けられ、オプションが解放されていたら、どうなるでしょうか。別の CPU は、すでに解放された、他の用途に使われうるメモリを読むことになります。これが、解放済みメモリの使用（UAF）です。

たとえるなら、次のような状況です。

• 予約票に、「付属の書類」がとじてある
• 本契約に切り替わるとき、書類は別のファイルへ移されて、元の場所は片付けられる
• ところが、別の窓口の人が、片付け直前の書類を、まだ読んでいる最中だった

2 つの CPU の動くタイミング次第で結果が変わる欠陥を、競合状態（レースコンディション） と呼びます。タイミングが合わなければ失敗しますが、失敗しても OS 全体が止まるとは限りません。Anthropic の記事も、負けた場合は接続が失敗するだけで、カーネル全体は落ちないため、攻撃者は繰り返し試せると説明しています。

修正の中身

修正は、オプションの解放方法を kfree() から kfree_rcu() に変えるものです。RCU は、今そのメモリを読んでいる処理がすべて終わるのを待ってから解放する仕組みです。これで、読んでいる途中の解放が起きなくなります。

IPv6 と、もう一つの経路

主な経路は IPv4 の通信です。IPv6 は、オプションをコピーする作り方なので、この主な経路の影響を受けません。ただし、要求ソケットを別の待ち受けへ移す機能（移行）では、似た問題があります。IPv6 側の移行の問題は、別の修正で対応される予定だと説明されています。

攻撃が成立する条件

脆弱なカーネルを使っていれば、すぐに攻撃されるわけではありません。報告されている条件を整理します。

MPTCP との関係

Anthropic の概念実証は、MPTCP の待ち受けを持つサーバーを対象にしていました。MPTCP は、1 つの接続で複数の通信経路を使うための TCP の拡張です。

大事なのは、MPTCP でなければ安全だとは言えない点です。Anthropic の記事は、MPTCP 以外の環境で攻撃が成り立つかどうかに触れていません。Go プロジェクトのセキュリティチームも、この欠陥自体は MPTCP に固有のものではなく、MPTCP の待ち受けがなくても、似た攻撃を受けうると注意しています。

Go のプログラムは要注意

Go 1.24 以降でビルドしたプログラムは、Linux では待ち受けソケットで MPTCP を既定で有効にします。自分では MPTCP を意識していなくても、知らないうちに MPTCP の待ち受けを持っている可能性があります。

攻撃の流れ（Anthropic の公表内容）

Anthropic の記事は、概念実証を 2 段階で説明しています。

1. カーネルのアドレスを探る: 競合状態を利用して、攻撃者が指定した長さのバイト列を返させ、カーネルの内部のアドレスを知る手がかりを得ます。
2. 処理の流れを乗っ取る: 同じ欠陥で、関数の呼び出し先を書き換え、あらかじめ置いたデータを使って、root 権限のコマンドを実行します。

この概念実証では、アドレスを探るのに 48 分、そこからコマンド実行まで約 5 分かかったとされています。成功まで時間がかかる一方で、何度でも試せる点に注意が必要です。

影響の大きさ: CVSS 9.8 をどう読むか

深刻度は、評価した組織によって分かれています。

差が出るのは、攻撃の難しさと、機密性・完全性への影響の見方です。競合状態を当てるには、多くの試行が要ります。この手間を重く見るか、軽く見るかで、評価が変わっています。

どれが正しいかを争うより、自分のサーバーに、外部から TCP で届くかを見るほうが、判断に役立ちます。インターネットに公開されたサーバーは、優先度が高くなります。内部だけで使うサーバーは、次の順番で構いません。

実行されるのは「root 権限」

攻撃が成功すると、コマンドは root 権限で動きます。サーバーの全ファイル、鍵、設定、他のサーバーへの接続情報が、危険にさらされます。

コンテナも守られない

見落としやすい点です。Docker や Kubernetes のコンテナは、ホストのカーネルを共有します。コンテナのイメージを最新に作り直しても、カーネルは更新されません。Kubernetes では、ノード（ホスト）のカーネルを更新し、再起動する必要があります。

対応策 1: カーネルを更新して再起動する（本命）

最も確実な対策は、修正済みのカーネルへの更新です。

自分のカーネルの版を調べる

# カーネルの版を表示
uname -r

# 移行機能が無効（0）であることを確認（既定は無効）
sysctl net.ipv4.tcp_migrate_req

ディストリビューションは、修正を古い版番号のカーネルへ移植（バックポート）して配るため、版番号だけでは判断できません。 判断は、ディストリビューションの告知に載る版と照らして行います。

上流の修正版

Linux カーネル本家の修正版は、次のとおりです。

ディストリビューション別の状況

確認日（2026年10月30日）時点で報告されている状況です。状況は日々変わるため、更新前に必ず各ディストリビューションの最新の告知を確認してください。

Debian では、通常のリポジトリに残る版が脆弱なままのことがあるため、security.debian.org を参照先に入れておく必要があります。Ubuntu と RHEL の状況は、主に報道や解説記事からの情報です。公式の告知で確認する必要があります。Raspberry Pi OS など、Debian をもとにした OS については、要確認です。

更新後は「再起動」まで終えて完了

カーネルは、更新しても、再起動するまで古いものが動き続けます。

• 再起動する: uname -r が、更新後の版になっているかを確認します。
• ライブパッチの場合: ディストリビューションが、この脆弱性向けのライブパッチを出しているかを確認します。
• Kubernetes の場合: ノードを 1 台ずつ、排出（drain）、更新、再起動、復帰の順に進めます。サービスを止めない運用になります。
• クラウドの場合: 提供元のマネージドなノードは、提供元の更新手順に従います。

対応策 2: すぐに更新できないときの暫定対処

更新の準備が整うまでの危険を下げる方法です。これらは更新の代わりにはなりません。

1. 移行機能が無効か確認する

先ほどの sysctl net.ipv4.tcp_migrate_req が 0 であることを確認します。既定は 0 です。これは、要求ソケットの移行を使う別の経路を閉じる効果しかありません。主な経路は閉じません。

2. MPTCP の待ち受けを洗い出す

MPTCP の待ち受けがないかを調べます。

# MPTCP の待ち受けを一覧する
ss -Mlnp

見つかったら、本当に必要かを確認します。不要なら止めます。ただし、MPTCP をなくしても、危険が完全にはなくならない点に注意してください。

3. Go のプログラムで MPTCP を無効にする

Go のセキュリティチームは、次の方法を示しています。

• 実行時の環境変数に GODEBUG=multipathtcp=0 を設定する
• ビルド時に、go.mod へ godebug multipathtcp=0 を書く
• ソケットごとに net.Dialer や net.ListenConfig の SetMultipathTCP を使う

Go チーム自身が、これは壊れやすい対策だと述べています。MPTCP の待ち受けが 1 つでも残れば、危険が残るためです。また、攻撃が MPTCP 経由に限られるという前提も、保証されていません。

4. IP オプションを入り口で落とす

IPv4 の「経路の記録（Record Route）」オプションを、ネットワークの入り口で落とす方法が、解説記事で紹介されています。nftables のルールで実現できますが、時刻の記録（Timestamp）のオプションは、nftables 1.0.9 では判別できないため、一部しか防げません。 どのベンダーも、これを有効な対策だと確認していません。補助的な手段として扱ってください。

暫定対処の落とし穴

• 暫定対処は、カーネルの欠陥を直しません。 攻撃の入り口を減らすだけです。
• ファイアウォールで、信頼できる相手にだけポートを開ける対処は、確実に効果があります。ただし、公開サービスには使えません。
• 暫定対処を入れたことで、更新を後回しにしないでください。

更新後に確認すること

更新したら、次の点を確認して完了にします。

1. uname -r が、修正済みの版（またはディストリビューションが示す版）になっていること。
2. Kubernetes の全ノードで、同じ確認をしていること。1 台でも漏れると、そのノード上のすべてのコンテナが危険です。
3. 更新前のカーネルログに、ip_options_build、ip_build_and_send_pkt、skb_under_panic といった記録がないこと。攻撃に失敗した場合でも、カーネルが異常を記録することがあります。
4. 暫定対処で入れた設定を、不要になったら見直すこと。

ログに該当する記録が残っていた場合は、更新と並行して、環境の点検を検討してください。

一度きりの騒ぎにしないために

カーネルの脆弱性は、毎月のように出ます。今回に限らず、備えておきたい点が 3 つあります。

• カーネルの更新手順を決めておく: どのサーバーを、どの順で、どう再起動するかを、平常時に決めておきます。緊急のときに迷わずに済みます。
• 再起動できる構成にする: 1 台止めても、サービスが続く構成にしておくと、更新を先送りする理由がなくなります。
• 公開しているポートを減らす: 必要な相手にだけ開ける運用は、未知の脆弱性にも効きます。

今回の件を通じて確認しておきたいこと

CVE-2026-98432 は、接続を成立させる処理の中で、メモリの持ち主が代わるタイミングが、別の CPU から見えてしまう欠陥です。要点をまとめます。

• 問題の箇所: IPv4 の TCP で、SYN の IP オプションを、コピーせず子ソケットへ渡す処理です。別の CPU が読んでいる間に解放されると、UAF が起きます。
• 影響の大きさ: Linux カーネルの評価は CVSS v3.1 で 9.8 です。Anthropic は、MPTCP の待ち受けを持つサーバーで、遠隔から root でコマンドを実行する概念実証を公表しました。確認日時点で、悪用の報告はありません。
• 対象: Linux 4.4 以降で、修正前のカーネルを使うサーバーです。コンテナも、ホストのカーネルを共有するため対象です。
• 対応: ディストリビューションの修正版へ更新し、再起動します。ノードも忘れずに更新します。
• 更新までの暫定対処: 公開ポートを絞り、MPTCP の待ち受けを洗い出して止め、Go のプログラムでは GODEBUG=multipathtcp=0 を検討します。

先に結論を書いたとおり、やることは「調べる、更新する、再起動する」です。まず、自分のサーバーのカーネルが、ディストリビューションの示す修正版かどうかを確認するところから始めてください。PHP や Brotli の件と違い、アプリではなく OS の更新が必要になる点が、今回の大きな違いです。