Linuxカーネルの脆弱性CVE-2026-98432とは、IPv4のTCP接続処理の解放後使用と修正版、MPTCPの確認

LinuxカーネルのIPv4のTCP接続処理に、解放済みのメモリを使ってしまう脆弱性CVE-2026-98432が見つかりました。接続を受け付けるサーバーに対し、認証のない遠隔の相手が送るパケットだけでカーネルのメモリが壊れ、メモリ内容の漏えい、カーネルの停止、条件によってはコードの実行につながりえます。CVEを採番したLinuxカーネルのCVEチームは、CVSS v3.1で9.8(Critical)と評価しています。

Anthropicは2026年10月27日に、マルチパスTCP(MPTCP)で待ち受けるLinuxサーバーに対して、遠隔からroot権限でコマンドを実行する実証を示しました。Goのチームは、Go 1.24以降のプログラムがLinuxで既定でMPTCPの待ち受けを使う点を挙げ、カーネルの更新を強く勧めています。

この記事は、LinuxサーバーでWebアプリやAPIを運用するインフラ担当と、Goでサーバーを開発するエンジニアに向けて、脆弱性の仕組み、影響版と修正版、ディストリごとの状況、更新までの暫定策を、CVEレコード、カーネルの修正、各ディストリと各プロジェクトの一次情報で整理します。攻撃を再現する手順は扱いません。事実は執筆時点(2026年11月2日)で確認できた範囲に限ります。

CVE-2026-98432はIPv4のTCP接続処理にある解放後使用#

TCPの接続は、クライアントのSYN、サーバーのSYN-ACK、クライアントのACKという3回のやり取りで確立します。IPv4のパケットには、経路を記録するRecord Routeや時刻を記録するTimestampといったIPオプションを付けられます。サーバーのカーネルは、SYNに付いていたIPオプションを、接続を確立するまでの間、接続要求ごとの領域に保存します。

CVEレコードの説明によると、欠陥は次のように起きます。接続が確立すると、カーネルは保存したIPオプションの領域をコピーせずに、新しく作るソケットへ引き渡します。ちょうどそのとき別のCPUが、同じ接続要求に対して再送されたSYNを処理し、保存済みのIPオプションを読みながらSYN-ACKを組み立てていることがあります。新しいソケットが閉じられると、IPオプションの領域は即座に解放されるため、SYN-ACKを組み立てている側は解放済みのメモリを読み書きしてしまいます。

この並行処理は、Linux 4.4で入った変更(接続要求をリスナーのロックを取らずに処理するようにした変更)から起こりうるようになりました。同じ種類の問題は、接続要求を別のソケットへ移し替える機能(net.ipv4.tcp_migrate_reqを1にした場合や、BPFのプログラムで移し替える場合)にもあると説明されています。修正では、読み手がまだ使っている可能性のある間は解放を遅らせる仕組み(RCU)を使って、領域を解放するように変えました。

CVEレコード(CNAはLinux)は、tcp_v4_syn_recv_sock()が接続要求のIPオプション(ireq_opt)をコピーせずに子ソケットへ渡し、別のCPUが再送SYNに応じてSYN-ACKを送る処理と競合すると説明しています。子ソケットのinet_sock_destruct()は通常のkfree()で領域を解放するため、ip_options_build()で解放後使用が起きます。IPv6は、オプションを複製しているため一つ目の問題の対象外とし、移し替えに関する同種の問題は別の修正で扱うとしています。

CNAがCVSSの評価に添えた説明では、攻撃者がIPオプション付きのSYNと再送SYNを送り、同じ接続の確立と切断を繰り返して競合を起こす想定です。解放済みの領域が再利用されると、そこにある古い長さの値をもとに、隣のメモリの内容がSYN-ACKに載って攻撃者へ送られたり、範囲外へ書き込まれたりします。カーネルが異常を検知して停止する場合もあります。並行処理の隙が脆弱性になる一般的な仕組みは、次の記事で整理しています。

あわせて読みたい

レースコンディション(競合状態)の仕組みと対策。チェックと使用の隙を原子性で塞ぐ

深刻度の評価#

執筆時点でNVDは独自の評価をまだ付けておらず、表示されているのはCNAの評価です。

Red Hatは、任意のコードを確実に実行するには時間の精密な制御が必要だとしつつ、前提条件がないこととシステムが不安定になる影響の大きさから、Criticalと評価しています。

Anthropicの実証と悪用の状況#

Anthropicは2026年10月27日の記事で、AIモデルのClaudeを使った脆弱性の発見と攻撃コードの作成の事例を公表し、その一つとしてこの脆弱性を挙げました。記事によると、MPTCPで待ち受けるLinuxサーバーに対し、遠隔の攻撃者がパケットを送るだけで、認証情報も利用者の操作もなしに、root権限で任意のコマンドを実行できたとしています。競合に失敗しても接続の確立が失敗するだけでシステムは止まらないため、攻撃者は何度でも試せると説明しています。修正はすでに上流で取り込まれ、保守中の安定版へバックポートされたとしています。

実地での悪用について、執筆時点で確認できた一次情報には記載がありません。2026年11月2日に取得したCISAのKEVカタログ(10月30日更新版)には、CVE-2026-98432は含まれていませんでした。JPCERT/CCとIPAの注意喚起も、執筆時点では確認できませんでした。ただし、実証の存在が公表されているため、悪用の確認を待たずに更新を進めます。

Goで書いたサーバーはMPTCPで待ち受けている場合がある#

MPTCPは、一つの接続で複数の経路を同時に使えるようにするTCPの拡張です。Anthropicの実証はMPTCPの待ち受けを使っていたため、どのサーバーがMPTCPで待ち受けているかが、まず確かめるべき点になります。

Goのセキュリティチームは2026年10月29日の告知で、Go 1.24以降のプログラムはLinuxで待ち受けのソケットに既定でMPTCPを使うと注意を促しました。Goの公式文書によると、この既定値(multipathtcp=2)は、Go 1.24以降のツールチェーンでビルドし、メインのモジュールのgo.mod(ワークスペースではgo.work)のgoの版が1.24以降の場合に適用されます。Goで書いたWebサーバーやAPIサーバーは、開発者が意識していなくてもMPTCPで待ち受けている場合があるため、実際の待ち受けを確かめます。カーネル側でMPTCPが使える状態かどうかはディストリや設定によって異なり、AlmaLinuxは既定でMPTCPを無効にしていると説明しています。

Goのプログラム単位でMPTCPを止める方法として、告知は次の3つを示しています。

• 実行時の環境変数にGODEBUG=multipathtcp=0を設定する
• メインのモジュールのgo.mod(ワークスペースを使う場合はgo.work)にgodebug multipathtcp=0を書き、ビルド時の既定を変える。変更後は再ビルドし、動いているプロセスを入れ替える
• net.ListenConfigやnet.DialerのSetMultipathTCPで、ソケットごとに明示する(GODEBUGの設定より優先されます)

ただしGoのチームは、プログラムごとに止める方法は脆い緩和策だとしています。MPTCPで待ち受けるプログラムが一つでも残れば露出が残るうえ、欠陥自体はMPTCPに固有のものではなく、MPTCPを使わないシステムにも似た攻撃が成り立つ可能性があるためです。Goの側で既定の挙動を変えるのは時期尚早とし、カーネルの更新を強く勧めています。

影響版と修正版#

CVEレコードによると、影響はLinux 4.4以降で、次の版で修正されています。

多くのサーバーは、ディストリが独自に修正を取り込んだカーネルを使っています。カーネルの版の数字だけでは判断できないため、各ディストリの修正済みパッケージで確かめます。執筆時点で確認できた状況は次のとおりです。

Red Hatの情報では、OpenShiftのノードに使うRHEL CoreOSなども影響を受ける製品として挙がっています。コンテナはホストのカーネルを共有するため、コンテナイメージを作り直しても直りません。ホストのカーネルを更新して再起動します。

更新できない間の暫定策#

暫定策はいずれも修正ではありません。カーネルを更新して再起動するまでの間、露出を減らすために使います。

IPオプション付きのTCPパケットを捨てる#

AlmaLinuxは、受信するTCPパケットのうち、IPv4のヘッダー長がオプションのない場合より長いもの(IPオプションを含むもの)を、nftablesで捨てる方法を示しています。AlmaLinuxは、このルールはふつうの接続には影響しないとしています。

注意点として、AlmaLinuxは次の点を挙げています。

• 設定は再起動で消えるため、再起動後は再び適用する
• 同じホストの上のコンテナ同士の通信は、このルールを通らない場合がある
• ルーターとして動くホストでは、転送するIPオプション付きのTCPパケットも捨てられる
• NetLabel(CIPSO)を使うネットワークでは使わない
• IPv6の通信には不要

MPTCPを止める#

MPTCPが不要なら、sysctlでnet.mptcp.enabledを0にして、システム全体で新しいMPTCPのソケットを作れないようにします。AlmaLinuxは、この設定は新しいソケットにしか効かないため、すでに開いているMPTCPの待ち受けはssコマンドで確かめ、該当するサービスを再起動するよう説明しています。oss-securityへの投稿では、実行中のプログラムが新しい接続で予期しないエラーを出す可能性も指摘されています。MPTCPに限らない欠陥のため、MPTCPを止めても露出がなくなるわけではありません。

メモリ解放時の初期化を有効にする#

2026年10月31日のoss-securityへの投稿は、追加の緩和策として、解放したメモリを0で埋めるカーネルの起動パラメータinit_on_free=1を挙げています。欠陥はそのまま残りますが、解放した時点で中身を消しておくことで、解放済みの領域から以前の内容を読まれる余地を減らすという考え方です。領域が別の用途に再び割り当てられた後の読み書きや、悪用そのものを防ぐものではありません。投稿者は、メモリの解放が多い処理で1から5パーセント程度の性能低下がよく言われるとして、自分の環境で測るよう勧めています。これはディストリの公式な案内ではなく、利用者からの提案である点に注意します。

公開するTCPのポートと接続元を絞る#

この欠陥は、TCPの接続を受け付けるサービスであれば、アプリケーションの認証より前の段階で到達します。インターネットに公開する必要のないポートは閉じ、管理用のポートは接続元を限定します。ファイアウォールで通信を絞る基本は、次の記事で整理しています。

あわせて読みたい

ファイアウォールが通信を許可と拒否で仕分ける仕組み

運用側がとる初動#

実証が公表されているため、露出の確認と更新を並行して進めます。次の順序で手を付けます。

同じ週には、Linuxでコンテナや仮想マシンを管理するLXDにも、遠隔から信頼済みのクライアントになりすませる脆弱性が公表されています。LXDを使うホストは、カーネルとあわせて確認します。

あわせて読みたい

LXDの脆弱性CVE-2026-112816とは、証明書チェーンの検証不備で信頼済みクライアントになりすませる問題と修正版

KEVに載っていない脆弱性の優先度をどう決めるかは、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

まとめ#

CVE-2026-98432は、IPv4のTCPの接続確立の処理で、SYNのIPオプションの領域が使われている最中に解放されてしまう脆弱性です。接続を受け付けるサーバーであれば、アプリケーションの認証より前の段階で到達し、AnthropicはMPTCPの待ち受けを経由した遠隔のroot取得を実証しました。

優先するのは、外部から到達できるホストのカーネルを修正版へ更新し、再起動することです。Go 1.24以降のサーバーはMPTCPで待ち受けている場合があるため、あわせて確認します。KEVへの登録やディストリの修正状況は今後も変わる可能性があるため、利用しているディストリの公式情報を引き続き確認します。