2026.10.30

【2026年10月】Linuxカーネルの脆弱性CVE-2026-98432の確認と対応｜MPTCPを止める暫定対応とカーネル更新の恒久対応

soflan ・読了 9分

はじめに

2026 年 10 月、Linux カーネルの TCP の処理に、ネットワーク越しにログインなしで root を取られるおそれのある脆弱性 CVE-2026-98432 が公表されました。10 月 27 日には、AI を使った研究で実際に攻撃が成り立つことが示され、大きく報じられました。

Linux 本体（上流）では直っていますが、Ubuntu や RHEL ではまだ修正版が出ていません（10 月 30 日時点）。この記事では、自分のサーバーが影響を受けるかの確認、修正版が出るまでの暫定対応、修正版が出てからの恒久対応を、手順つきでまとめました。コマンドは Ubuntu を例にしています。

脆弱性の概要

番号	CVE-2026-98432
場所	Linux カーネルの IPv4 の TCP の処理（接続を受け付けるところ）
種類	解放したメモリを使ってしまう不具合（use-after-free）
影響	ネットワーク越しに、ログインなしで root を取られるおそれ
深刻度	CVSS 9.8（Red Hat の評価は 8.1）
対象	カーネル 4.4 以降
公表	2026 年 10 月 15 日

TCP の接続を受け付けるとき、相手が IP オプションを付けて SYN を送ってくると、そのオプションを入れたメモリを複数の処理で共有します。片方がそのメモリを解放したあとに、もう片方（再送された SYN への応答を組み立てる処理）が読んでしまうことがある、という不具合です。

10 月 30 日時点で、実際の攻撃に使われたという報告はありません。ただ、攻撃が成り立つことは示されているので、早めの対応をおすすめします。

MPTCP との関係

MPTCP（マルチパス TCP）は、1 つの接続で複数の経路（Wi-Fi とモバイル回線など）を同時に使える、TCP を広げたしくみです。Linux では 5.6 から入っていて、Ubuntu などでは標準で使える状態になっています。

公開された攻撃の手順は、MPTCP で待ち受けているサーバーを狙うものです
ただし、不具合そのものは普通の IPv4 の TCP の処理にあります。MPTCP を止めても、ほかの攻撃の経路がないとは言い切れません
つまり、MPTCP を止めるのは「修正版が出るまでの時間かせぎ」です

気づかないうちに MPTCP で待ち受けているもの

普通のソフトは MPTCP を使いませんが、Go で書かれたプログラムは注意が必要です。Go は 1.24 から、待ち受けのときに標準で MPTCP を使うようになりました。自分で書いた Go のサーバーのほか、Go で作られた道具（Docker のポートの転送をする docker-proxy、リバースプロキシ、監視のエージェントなど）も、MPTCP で待ち受けている可能性があります。

確認 1：カーネルの版

まず、動いているカーネルの版を確かめます。

bash

uname -r

ディストリビューションのカーネルは、上流の修正を古い版の番号のまま取り込むので、上流の版の番号とは比べられません。自分のディストリビューションの発表と比べてください。

ディストリビューション	状態（10 月 30 日時点）
Ubuntu 26.04 LTS	修正作業中（7.0.0-43 を準備中）
Ubuntu 24.04 LTS	修正作業中（6.8.0-149 を準備中）
Ubuntu 22.04 LTS	修正作業中（5.15.0-203 を準備中）
Ubuntu 20.04 以前	修正版の予定なし（14.04 は影響なし）
Debian 12・13	修正済み（6.1.190・6.12.113）
RHEL 8・9・10	影響あり、修正版はまだ

たとえば Ubuntu 24.04 で 6.8.0-124-generic と出たら、直る版（6.8.0-149）より前なので影響を受けます。参考までに、上流の直った版は次のとおりです。自分でカーネルをビルドしている場合は、これと比べます。

系列	直った版
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	7.3（正式版）

確認 2：MPTCP で待ち受けているか

bash

# MPTCP のソケットを作れる設定か（1 なら作れる。標準は 1）
sysctl net.mptcp.enabled

# MPTCP で待ち受けているポートとプログラム（何も出なければなし）
sudo ss -Mltnp

ss -Mltnp に何も出なければ、いまは MPTCP で待ち受けているものはありません
0.0.0.0 や *、[::] で待ち受けているものが出たら、外から届く状態です。いちばん急いで対応します
127.0.0.1 だけで待ち受けているものは、外からは届きません

あわせて、カーネルの更新が来ているか、再起動待ちになっていないかも見ておきましょう。

bash

# 入っているカーネル（動いているものより新しい版があれば、再起動で切り替わる）
ls /boot/vmlinuz-*

# 再起動が必要か（何か出たら必要）
cat /var/run/reboot-required 2>/dev/null

# カーネルの更新が来ているか
sudo apt update && apt list --upgradable 2>/dev/null | grep -E 'linux-(image|generic)'

今回の修正版はまだですが、ほかの修正がたまっているなら、先に上げて再起動しておきましょう。uname -r が古いままなら、更新したのに再起動していないことがよくあります。

暫定対応：MPTCP を止める

修正版が出るまでは、MPTCP を止めて、公開された攻撃の経路を塞ぎます。MPTCP を使っていないサーバーなら、止めても困ることはまずありません。

1. ホストで止める

bash

# 再起動しても止めたままにする設定を置いて、すぐに読み込む
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
sudo sysctl --system

# 0 になったか確かめる
sysctl net.mptcp.enabled

2. MPTCP で待ち受けていたプログラムを再起動する

この設定で止まるのは、これから作るソケットだけです。確認 2 で ss -Mltnp に出ていたプログラムは、再起動して待ち受けをやり直させます。

bash

# systemd のサービスなら
sudo systemctl restart <サービス名>

# Docker のポートの転送（docker-proxy）が出ていたら、コンテナを作り直す
cd <docker-compose.yml のあるディレクトリ>
docker compose up -d --force-recreate

# もう一度確かめる（何も出なければよい）
sudo ss -Mltnp

3. コンテナの中も止める

net.mptcp.enabled はネットワークの名前空間ごとの設定です。Docker のコンテナは、ホストとは別の名前空間を持つので、ホストで止めてもコンテナの中には効きません。コンテナの中で Go のサーバーがポートを公開しているなら、コンテナでも止めます。

docker-compose.yml

services:
  app:
    # このコンテナの中でも MPTCP を止める
    sysctls:
      net.mptcp.enabled: 0

なお、コンテナはホストのカーネルをそのまま使います。コンテナのイメージを新しくしても、この脆弱性は直りません。直すのはホストのカーネルです。

4. Go のプログラムで止める

sysctl を変えられない環境（共有のサーバーなど）では、Go のプログラムの側で MPTCP を使わないようにできます。

bash

# 起動するときに指定する
GODEBUG=multipathtcp=0 ./server

go.mod

// ビルドするときに組み込む（main のモジュールの go.mod に書く）
godebug multipathtcp=0

ただし、コードの中で SetMultipathTCP(true) を呼んでいると、この指定は効きません。プログラムごとに止めるやり方は漏れやすいので、できるならホストの sysctl で止めましょう。

5. ついでに見ておくこと

sysctl net.ipv4.tcp_migrate_req が 1 になっていたら、この不具合に関わるもう 1 つの経路が開いています。標準は 0 なので、自分で変えた覚えがなければそのままで大丈夫です
ファイアウォールで、外に開けるポートを必要なものだけにしておく（これで不具合が直るわけではありませんが、狙われる場所は減ります）

暫定対応でできないこと

MPTCP を止めて塞がるのは、公開された攻撃の経路だけです。不具合そのものは残っているので、修正版が出たら必ずカーネルを更新します。

恒久対応：カーネルを更新する

ディストリビューションから修正版が出たら、カーネルを更新して再起動します。カーネルは、再起動するまで新しくなりません。

bash

sudo apt update
sudo apt upgrade

# 再起動（サービスが止まるので、時間を選ぶ）
sudo reboot

# 再起動したら、版を確かめる（Ubuntu 24.04 なら 6.8.0-149 以降）
uname -r

Ubuntu の場合は、CVE のページで自分の版の状態が「Fixed」になったかを見ます
再起動の前に、Docker のコンテナなどが自動で起き上がる設定（restart: unless-stopped など）になっているか確かめておくと安心です
再起動のあとに uname -r を見るまでが対応です。更新しただけで終わりにしない

直ったあと、MPTCP をどうするか

修正版に上げたあとは、MPTCP を元に戻しても構いません。ただ、使っていないなら止めたままにするのも手です。使わない機能を閉じておけば、MPTCP に別の不具合が見つかったときの影響も減らせます。戻すなら、置いた設定ファイルを消して読み込み直します。

bash

# MPTCP を元に戻すとき
sudo rm /etc/sysctl.d/99-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=1

次に備えて

unattended-upgrades でセキュリティの更新を自動で入れ、再起動が必要になったら気づけるようにしておく（/var/run/reboot-required を監視するなど）
再起動できる時間帯を決めておくと、今回のような急ぎのカーネルの更新も慌てずに済みます
サーバーで何が、どのポートで待ち受けているかを、ときどき ss -ltnp で棚卸しする

進める順番

uname -r でカーネルの版を確かめ、ディストリビューションの発表と比べる
ss -Mltnp で MPTCP で待ち受けているものを確かめる（外に開いているものを優先）
ホストで net.mptcp.enabled = 0 を設定し、待ち受けていたプログラムを再起動する
コンテナや Go のプログラムで MPTCP を使っていたら、そちらも止める
修正版が出たら、カーネルを更新して再起動し、uname -r で確かめる

まとめ

CVE-2026-98432 は、Linux カーネルの IPv4 の TCP の処理の不具合で、遠隔から root を取られるおそれがある（CVSS 9.8）
Ubuntu・RHEL は 10 月 30 日時点で修正版がまだ。Debian 12・13 は修正済み
公開された攻撃は MPTCP で待ち受けるサーバーが対象。Go 1.24 以降のプログラムは、標準で MPTCP で待ち受ける
暫定対応は net.mptcp.enabled = 0 と、待ち受けていたプログラムの再起動。コンテナは別に止める
恒久対応はカーネルの更新と再起動。暫定対応だけで終わりにしない

サポートが終わった Linux を使っている場合は、修正版そのものが出ません。【2026年版】CentOS 7などサポートが終わったLinuxからの移行手順もどうぞ。