Linuxカーネルの脆弱性CVE-2026-98432：修正版の見分け方とnftablesの緩和策

Linuxカーネルの脆弱性CVE-2026-98432は、IPv4のTCP接続を確立する処理で、解放済みのメモリを読んでしまう欠陥です。カーネル4.4から入り込んでおり、CVSS 3.1の評価は9.8です。Anthropicは、MPTCPのリスナーを持つサーバーに対して、認証なしでroot権限のコマンドを実行できることを実証しました。この記事では、影響するカーネルの見分け方、Debian・Ubuntu・RHEL系・Amazon Linuxの修正状況、更新と再起動の手順、更新までの緩和策を、2026年11月4日時点の一次情報で整理します。

まとめ：修正済みカーネルへ更新して再起動し、それまではIPオプション付きTCPを遮断

対応の本線は、修正済みのカーネルを入れて再起動することです。パッケージを更新しただけでは、古いカーネルが動き続けます。Debian・AlmaLinux・Amazon Linuxは修正版を出しており、UbuntuとRHELは2026年11月4日時点で準備中の表示でした。

修正版が届くまでは、IPオプションを含むIPv4のTCPパケットをnftablesで捨てます。Red HatとAlmaLinuxが示している緩和策で、サービスの再起動は要りません。MPTCPを止めるだけでは足りない点に注意してください。

優先するのは、インターネットからTCPで届くサーバーと、Kubernetesのノードです。台数が多く、どこから手を付けるか決めにくい場合は、脆弱性診断・セキュリティ診断で露出の棚卸しから進めると漏れが出にくくなります。

CVE-2026-98432の中身：IPv4のTCP接続確立で起きる解放後使用とRCE実証

NVDへの登録は2026年10月15日で、最終更新は11月3日です。採番したのはLinuxカーネルのCNAで、NVD自身の評価はまだ付いていません（vulnStatusはReceived）。

tcp_v4_syn_recv_sock()のIPオプション引き渡しと複製省略

TCPの3ウェイハンドシェイクでは、SYNを受けたカーネルが「リクエストソケット」を作り、ACKが返ってきた時点で本物の子ソケットへ切り替えます。SYNにIPオプションが付いていると、その写しがリクエストソケットに保存されます。

カーネルCVEチームの公告によると、tcp_v4_syn_recv_sock()はこの写しを複製せず、子ソケットへそのまま渡していました。子ソケットが閉じると、inet_sock_destruct()が通常のkfree()で解放します。同じ接続の再送SYNを別のCPUが処理していると、解放済みの領域をip_options_build()が読んでSYN-ACKを組み立ててしまいます。

修正は、解放をkfree_rcu()に変え、読み手が使い終わるまで待つものです。手が入るファイルは、net/ipv4/af_inet.cとnet/ipv4/tcp_ipv4.cの2つに限られます。リクエストソケットを別のリスナーへ移すnet.ipv4.tcp_migrate_reqでも同じ問題があり、こちらは既定で無効です。IPv6は最初の問題の影響を受けません。カーネルの役割分担そのものはカーネルの役割と仕組みで整理しています。

AnthropicのMPTCPリスナー実証と、MPTCPを使わない環境に残る危険

発見者のAnthropicは、2026年10月27日の研究記事で攻撃の実証を公開しました。対象はMPTCP（マルチパスTCP）のリスナーを持つLinuxサーバーで、攻撃者はパケットを送るだけです。認証情報も、利用者の操作も要りません。

実証では、カーネルのアドレスを漏らすまでに48分、その後シェルのコマンドを実行するまでに5分かかっています。競合に負けてもハンドシェイクが失敗するだけで、サーバーは落ちません。攻撃者は気づかれずに何度でも試せます。

誤解しやすいのは、MPTCPを使っていなければ無関係だという読み方です。Goチームはoss-securityへの注意喚起で、根本のバグはMPTCPに固有ではないと書いています。実証された経路がMPTCPだったというだけで、欠陥は通常のIPv4 TCPの処理にあります。

CVSS 9.8と8.1の評価差：カーネルCNAと各配布元の攻撃条件の見方

深刻度の評価は、配布元によって割れています。

差は「攻撃の複雑さ」の評価から来ています。タイミング頼みの競合を突く必要があるため、Amazon Linuxは高いと見ました。Red HatのCVEページは、任意コードの実行には精密なヒープ操作が要ると認めたうえで、前提条件なしにカーネルを落とせる点を重く見てCriticalにしています。各指標の読み方はCVSSv3のスコアの目安と計算式で確認できます。私たちの対応判断で採る評価は、9.8の側です。実証が公開済みで、失敗しても痕跡が残りにくい種類の攻撃だからです。今年のカーネル脆弱性ではCVE-2026-31431（Copy Fail）もありましたが、あちらはローカルからの権限昇格で、ネットワーク越しに届く今回とは前提が違います。

影響するカーネルの見分け方：上流の修正版とディストリ別の対応状況

判定は「上流の修正版」と「ディストリの修正パッケージ」の2段で行います。業務で使うサーバーは、ほぼ後者で判断することになります。

上流の修正版8系統と、4.4以降の修正前カーネルが対象になる条件

カーネルCVEチームの公告では、欠陥は4.4のコミットで入り込み、次の版で直っています。

この表で判定できるのは、上流の版番号をそのまま使う自前ビルドや一部のクラウド向けカーネルです。表に無い系統、たとえばサポートが終わった6.19系は修正版が出ません。6.19系の扱いはLinuxカーネル6.19のサポート終了と移行で整理しています。

11月4日時点の修正パッケージ：Debian・Ubuntuと各配布元の対応

ディストリのカーネルは独自の版番号で修正を取り込むため、上の表とは突き合わせられません。各社の公開ページで確かめた状況は次のとおりです。

Debianはセキュリティトラッカー、UbuntuはCVEページ、Amazon LinuxはALASの一覧が出典です。AlmaLinuxのブログは、8系が4.18.0-553.182.1.el8_10、10系が6.12.0-211.72.1.el10_2で、11月2日から通常の更新に載ったと書いています。

Ubuntuは、26.04・24.04・22.04に修正予定の版数（24.04なら6.8.0-149.149）を示しつつ、状態は「作業中」でした。20.04以前は修正予定の表示がありません。Amazon Linux 2023では、kernel6.12（ALAS2023-2026-3335）とkernel6.18（ALAS2023-2026-3251）が先に直っています。Amazon Linux 2を使い続けている場合は、Amazon Linux 2からAL2023への移行手順もあわせて見直してください。状況は日々動くため、作業の直前に各ページを開き直してください。

uname -rとパッケージの変更履歴で自分のサーバーを判定するコマンド

確認するのは、いま動いているカーネルの版と、その版に修正が入っているかの2点です。

# いま動いているカーネルの版
uname -r

# RHEL系・AlmaLinux・Amazon Linux：動いているカーネルの変更履歴にCVE番号があるか
rpm -q --changelog kernel-$(uname -r) | grep -m1 CVE-2026-98432

# Debian・Ubuntu：動いているカーネルのパッケージ版を表示し、上の表と比べる
dpkg -l "linux-image-$(uname -r)" | tail -n 1

# MPTCP のリスナーがあるか（あれば優先度を上げる）
sudo ss -lnMp

これらのコマンドは各ディストリの標準コマンドで、私たちは今回の判定には実行していません。RHEL系の変更履歴にはCVE番号が載るのが通例ですが、載っていない場合は上の表の版数で判断します。uname -rと/etc/os-releaseの使い分けはLinuxのバージョン確認コマンドで解説しています。

修正カーネルへの更新手順：apt・dnfでの入れ替えと再起動後の確認

カーネルの更新は、ファイルを入れ替えただけでは効きません。再起動して新しいカーネルで立ち上がった時点で、初めて修正が有効になります。

apt・dnf更新コマンド：Debian・UbuntuとRHEL系などの手順

# Debian・Ubuntu
sudo apt update
sudo apt full-upgrade
sudo reboot

# RHEL・AlmaLinux・Rocky Linux・Amazon Linux 2023
sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

# Amazon Linux 2
sudo yum update kernel
sudo reboot

AlmaLinuxの手順はdnf clean metadataのあとdnf upgradeで全体を上げる形です。上の例はカーネルだけに絞っていますが、ほかの更新が溜まっているなら同時に済ませた方が再起動は1回で済みます。Amazon Linux 2023でkernel6.12やkernel6.18を選んで入れている場合は、パッケージ名をそちらに置き換えます。コマンドは各社の公開手順をもとに書いたもので、私たちは未実行です。

再起動を挟まないと修正が効かない理由と、旧カーネルのまま動くサーバーの検出

見落としが多いのはここです。パッケージの更新が終わっても、メモリ上で動いているのは古いカーネルのままです。

# RHEL系：再起動が必要なら終了コード1と理由を表示（dnf-utils が必要）
sudo needs-restarting -r

# Debian・Ubuntu：再起動待ちの印となるファイル
cat /var/run/reboot-required 2>/dev/null

# 共通：インストール済みの最新カーネルと、動いているカーネルを並べて比べる
ls -1 /boot/vmlinuz-* | sort -V | tail -n 1
uname -r

2つの版が違えば、再起動が済んでいません。構成管理ツールで更新を配っている環境では、更新と再起動を別の作業として管理していることがあります。台帳の「適用済み」が、再起動まで含んでいるかを確かめてください。更新から再起動までを自動化する仕組みはパッチ管理の手順で扱っています。

更新までの緩和策：nftablesでIPオプション付きTCPを捨てる設定とMPTCPの扱い

修正版が届かない、またはすぐ再起動できない場合の時間稼ぎです。どれも修正の代わりにはなりません。

Red HatとAlmaLinuxのnftablesルールの違いと適用・削除の手順

攻撃には、IPオプションの付いたSYNが要ります。IPv4のヘッダ長（ip hdrlength）は4バイト単位で、オプションが無ければ5です。5を超えるTCPパケットを捨てれば、欠陥のある処理にオプションが渡りません。Red HatのRHSB-2026-016は、次の内容をcve-2026-98432.nftとして保存する手順を示しています。

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

# 文法を確かめてから読み込み、適用されたかを表示
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

# 修正カーネルで再起動したあとに外す
sudo nft delete table inet cve_2026_98432

AlmaLinuxのルールは、フックがinputではなくpreroutingです。ホスト宛てに加えて、ホストを経由してDockerやPodmanのコンテナへ届くパケットも捨てられます。コンテナを動かすホストに向いているのは、AlmaLinux側の書き方です。どちらのルールも再起動で消えるため、修正カーネルを入れる前に再起動した場合は読み込み直します。nftablesとiptablesの関係はiptablesとnftablesへの移行で整理しています。これらのルールは公式の記載をそのまま写したもので、私たちは未実行です。

CIPSO・転送経路・同一ホストのコンテナ間通信でルールが効かない場面

このルールを入れてはいけない環境、入れても守れない経路があります。

• CIPSOのセキュリティラベル（NetLabel）を使う環境：ラベルがIPオプションに載るため、正規の通信まで止まります。AlmaLinuxは使わないよう明記しています。
• ルーターやゲートウェイとして転送するホスト：転送するTCPのうち、IPオプション付きのものも捨てます。
• 同じホストの上のコンテナ同士の通信：ホストのフィルタを通らないため、ルールを迂回できます。

3つ目は、Kubernetesのノードで問題になります。Red HatはOpenShift 4について、OVN-Kubernetesの中を流れるPod間の通信はフィルタされず、Pod間通信向けの緩和策は今のところ無いと書いています。ノードへのルール適用で守れるのは外部からの通信だけで、マルチテナントのクラスタでは更新を急ぐ以外に手がありません。

MPTCPの無効化設定とGoの環境変数による制御：新規ソケットへの適用範囲

MPTCPを止める方法も紹介されていますが、効く範囲は限られます。カーネル公式のMPTCPのsysctlでは、net.mptcp.enabledの既定値は1（有効）です。一方、RHELとAlmaLinuxは配布時点で無効にしています。

# 現在の設定（1なら新しいMPTCPソケットを作れる）
sysctl net.mptcp.enabled

# MPTCPを使っていないなら止める（再起動後も維持）
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

# 既に開いているMPTCPリスナーは残るので、持ち主のサービスを再起動する
sudo ss -lnMp

この設定が止めるのは、新しく作るMPTCPソケットだけです。Red Hatは、MPTCPが既定で無効のRHELでは設定しても効果が無く、脆弱なままだと書いています。実証された経路を塞ぐだけで、通常のTCPに残る欠陥には効きません。

Goで書いたサーバーには別の事情があります。GoのGODEBUGの公式説明によると、Go 1.24からmultipathtcpの既定値が2になり、リスナーではMPTCPが既定で有効です。カーネル側が有効なら、Go製のサービスは何も設定しなくてもMPTCPで待ち受けます。サービスごとに止めるなら環境変数GODEBUG=multipathtcp=0か、go.modのgodebug multipathtcp=0を使います。既定値を無効に戻す提案はgolang/goのissue 82717で議論中です。Goの実行環境の基本はGo言語の実装入門で扱っています。

init_on_free=1のゼロ埋めを今回の緩和策に数えない理由

oss-securityでは、解放したメモリをゼロで埋める起動パラメータinit_on_free=1も暫定策として提案されました。これに対し、カーネル開発者の返信は、解放前の中身は攻撃に使われておらず緩和にならないと反論しています。問題は解放後に同じ場所へ別のデータが置かれることで、ゼロ埋めはそれを止めません。性能が1〜5%落ちうる設定でもあり、私たちはこの件の対策としては入れません。

更新優先度の判断基準：インターネット公開・Kubernetesノード・社内サーバー

全台を同じ日に再起動できる組織は多くありません。順番を決める基準を、条件付きで示します。

当日中に再起動するサーバーと、計画停止まで緩和策で待てるサーバーの線引き

当日中に再起動するのは、次のどれかに当てはまるサーバーです。

1. インターネットからIPv4のTCPで直接届く：Webサーバー、APIサーバー、踏み台、メールサーバー
2. MPTCPのリスナーがある：ss -lnMpに何か出る、またはGo 1.24以降で作ったサービスが動いていてカーネルのMPTCPが有効
3. 他社や他部署のコンテナを載せるKubernetesのノード

ロードバランサーの裏にあり、外部と直接TCPを結ばないサーバーは、nftablesのルールを入れたうえで次の計画停止まで待てます。前段の装置がTCPを終端せずにパケットをそのまま通す構成なら、「直接届く」側に数えます。IPv6だけで待ち受けるサービスは、今回の主な欠陥の対象外です。

逆に、緩和策で待つべきでない場面もあります。CIPSOを使う環境と、Pod間通信を守れないマルチテナントのクラスタです。ここはルールで時間を稼げないため、修正版が出ていればすぐに入れます。出ていなければ、外部からの入口を一時的に絞ります。

同じ型のカーネル脆弱性が続くときにサーバー台帳へ残す3つの判断記録

今年はCopy Fail、Dirty Frag、今回と、カーネルの重大な脆弱性が続きました。次の公表で慌てないために、サーバーごとに次の3点を記録しておくと判断が速くなります。

• 動いているカーネルの版と、最後に再起動した日時
• インターネットから届くTCPポートの有無と、前段のロードバランサーの種類
• コンテナを載せているか、MPTCPやIPオプションを業務で使うか

この3点が揃っていれば、今回なら「当日再起動」「緩和策で待つ」の振り分けが台帳だけで済みます。自社だけでは露出の洗い出しが追いつかない場合は、脆弱性診断の種類と外注時の判断基準で進め方を確かめてください。

Linuxカーネルの脆弱性CVE-2026-98432でよく受ける質問と回答

対応を進める中で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

MPTCPを使っていないサーバーも更新が必要ですか？

必要です。欠陥があるのは通常のIPv4 TCPの接続処理で、MPTCPは実証に使われた経路の1つにすぎません。Goチームとカーネル開発者は、MPTCPを止めるだけでは不十分だとoss-securityで述べています。Red Hatも、MPTCPが既定で無効のRHELが脆弱なままだと明記しています。修正済みのカーネルへの更新と再起動が必要です。

IPv6だけで通信しているサービスも影響を受けますか？

カーネルCVEチームの公告は、IPv6は最初の問題の影響を受けないとしています。ただし、同じサーバーがIPv4でも待ち受けていれば、そちらが攻撃の入口になります。ss -ltnで待ち受けのアドレスを確かめ、0.0.0.0やIPv4のアドレスが出るなら対象として扱ってください。リクエストソケットを移す機能のIPv6側の同種の問題は、別の修正で扱うとされています。

コンテナイメージを更新すれば対策になりますか？

なりません。コンテナはホストのカーネルを共有するため、直すのはホスト側のカーネルです。Dockerのホスト、Kubernetesのノード、ECSのコンテナインスタンスなどを更新して再起動します。AWS FargateやGoogle Cloud Runのように基盤側がカーネルを持つサービスでは、提供元の対応状況を確かめます。

nftablesのルールを入れると、通常の通信に影響は出ますか？

一般的なWebやAPIの通信で、IPオプションを付けたTCPはほとんど使われません。影響が出るのは、CIPSOのラベルを使う環境と、IPオプションを前提にした特殊な機器との通信です。Red Hatは、本番へ入れる前に検証環境で通信を確かめるよう求めています。counterの値を見れば、実際に捨てたパケットの数を確かめられます。

実際に悪用されているかはどこで確かめられますか？

2026年11月4日時点で、一次情報に悪用を確認したという記載は見当たりません。Anthropicの実証と、Security NEXTの報道にある「実証報告」は、攻撃が成立することを示すものです。悪用の有無は、米CISAのKEVカタログへの登録と、各ディストリの公告の更新で追います。実証が公開されている以上、悪用の確認を待たずに更新を進めてください。

関連記事

• CVE-2026-31431（Copy Fail）とは｜ディストリ別の修正版・GKEとEKSの対応と緩和策：同じ年に出た、ローカルからの権限昇格につながるカーネル脆弱性です。
• Dirty Frag(CVE-2026-43284/43500/46300)とは｜Copy Fail 2の影響範囲と修正版・緩和策：Copy Failの続きとして見つかったカーネル脆弱性の修正版と緩和策です。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：更新から再起動までを自動化する仕組みづくりです。
• iptablesとは？Linuxのパケットフィルタとファイアウォール設定・nftablesへの移行を実装目線で解説：緩和策のnftablesルールを読むための基礎です。
• Linuxのバージョン確認コマンド｜OSはos-release、カーネルはuname -rで見る：影響判定の出発点になる版の確かめ方です。