2026/10/31 9:44 追記
以下、本件の続いての対応策を記しています
概要
2026年10月15日、LinuxカーネルのIPv4 TCP処理に関する脆弱性 CVE-2026-98432 が公表されました。
CVSS 3.1の評価は9.8（Critical）。認証を必要とせず、ネットワーク経由で攻撃が成立する可能性がある脆弱性です。
今回の問題は、TCP接続の確立処理において、使用中のメモリ領域を適切なタイミングで解放できていなかったことに起因します。
筆者のように公開サーバーを運用している方は、カーネルの更新が必要になるため、対応状況を確認しておきたいところです。
今回は、脆弱性の原因と影響を整理したうえで、Ubuntuにおける修正カーネルの適用方法と、パッチが提供されるまでの暫定的な対応についてまとめます。
筆者環境
- OS：Ubuntu 24.04 LTS
- Kernel：Linux（Generic）
- 対象：IPv4 TCP処理
- CVE：CVE-2026-98432
- 公開サーバー：Apache等を運用
1. 脆弱性の概要
今回の脆弱性は、LinuxカーネルのIPv4ネットワーク処理に存在する Use-After-Free（解放済みメモリへのアクセス） です。
問題となったのは、TCP接続の確立処理で使用するソケットオプションの解放タイミングです。
具体的には、tcp_v4_syn_recv_sock()による子ソケットの生成と、再送されたSYNパケットに対するSYN-ACKの生成が並行して実行された場合、同じメモリ領域を参照しているにもかかわらず、先にメモリが解放されてしまう可能性があります。
本来、複数のCPUコアから参照される可能性があるメモリについては、RCU（Read-Copy-Update）の猶予期間を経てから解放する必要があります。
ところが、修正前の処理では通常のkfree()によって即座に解放していました。
修正では、この部分をkfree_rcu()に変更し、参照中の処理が完了するまでメモリの解放を遅らせています。
つまり、今回の問題はメモリを解放する処理そのものではなく、他の処理がまだ参照している可能性を考慮せずに解放していたことにあります。
1.1. 影響とリスク
悪意のある細工を施したTCPパケットによって、この競合状態を発生させられた場合、主に次のような影響が考えられます。
- サービス停止（DoS） 解放済みのメモリを参照した結果、カーネルパニックが発生し、OS全体が停止する可能性があります。
- メモリ破壊 解放されたメモリ領域が別の用途に再利用された場合、予期しないメモリアクセスが発生する可能性があります。 メモリ破壊を利用した権限昇格やコード実行もリスクとして考えられます。
今回の問題はアプリケーションのログイン処理などを経由するものではなく、OSのTCP/IP処理層で発生します。
そのため、Webサーバーに認証機能を設けたり、SSHのログイン制限を強化したりするだけでは対処できません。
1.2. CVSS 9.8という評価について
今回の脆弱性はCVSS 3.1で9.8と評価されていますが、ディストリビューションによって評価には差があります。
例えばRed Hatでは、攻撃に必要な競合状態を成立させる難しさを考慮し、CVSS 3.1で5.9と評価しています。
とはいえ、攻撃が成立した場合にOS全体が停止する可能性があること、ネットワーク経由で認証なしに攻撃できる可能性があることは変わりません。
公開サーバーを運用する立場としては、修正パッケージの提供状況を確認し、対応を進めておきたいところです。
2. フェイズゼロ：政治交渉
さて、技術的な対策に入る前に、もう一つ済ませておくべきことがあります。
政治交渉です。
個人で運用しているサーバーであれば、作業時間も再起動のタイミングも自分の裁量で決められます。
しかし、組織で運用しているサーバーとなれば話は変わります。
- カーネルの脆弱性が公表された
- 修正済みカーネルへの更新が必要である
- 更新を反映するためにOSの再起動を伴う
- その間、サービスが一時的に停止する
- ついては、○時頃から○分程度の作業時間をいただきたい
といった、利用者への周知という名の政治交渉が必要になります。
このあたりは運用者の政治的な立ち位置、つまり、担当者や担当部門がどこまで強権を振るえるかによっても言い方や手段が変わってきます。
ただし、今回に限っては少々強気に出てもよいのではないかと筆者は考えています。
昨今、サイバー攻撃によるサービス停止や情報漏洩がこれだけ問題になっている状況です。
その中で、CVSS 9.8という重大な脆弱性が公表され、しかもネットワーク経由で攻撃される可能性がある。
ここまで条件が揃っているのであれば、
「業務に影響が出るので作業を控えてほしい」という要求に対して、「脆弱性を放置することによる業務への影響をどう評価するのか」と切り返すだけの材料は十分にあります。
予定した時間にサービスを停止することと、攻撃によって予期しない時間にサービスが停止すること。
どちらが業務に与える影響を制御しやすいかは、考えるまでもないでしょう。
そのため、今回は「作業を実施してよいでしょうか」というお願いよりも、
「重大な脆弱性への対応として、以下の時間帯に緊急メンテナンスを実施します」
という、実施を前提とした周知を提案したいところです。
実際にどこまで踏み込めるかは、組織の権限や運用ルール次第です。緊急変更の手続きが定められているのであれば、それに従って進めます。
ただ、こういうときのために緊急変更という仕組みが存在するのですから、使えるものは使っていきましょう。
※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。
また、再起動を伴う作業ですから、実施前には復旧手順や切り戻し方法も確認しておきます。
- 旧カーネルから起動できるか
- VPSの管理コンソールから操作できるか
- バックアップやスナップショットは取得できているか
- 再起動後にサービスが正常稼働しなかった場合、どう復旧するか
このあたりを押さえたうえで作業に入ります。
以下の手順は、
- 個人運用なので、そもそも政治交渉が不要
- 組織内でフェイズゼロをクリアした
方向けのものです。
技術的には数分で終わる作業でも、その数分を確保するために何日もかかる。
サーバー運用とは、往々にしてそういうものです。
ですが、今回のような脆弱性対応では、その何日間をどこまで短縮できるかも、運用者の仕事だと考えています。
3. さっくりとした手順
以下の流れで対応します。
3.1. 事前確認
- 現在のカーネルを確認します。
uname -r - MPTCPの設定を確認します。
sysctl net.mptcp.enabled - MPTCPの使用状況を確認します。
sudo ss -Mlnp - TCPリクエスト移行機能の設定を確認します。
sysctl net.ipv4.tcp_migrate_req
3.2. 暫定対応
- MPTCPを無効化します。
sudo sysctl -w net.mptcp.enabled=0 - 設定ファイルを作成します。
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf - 設定を反映します。
sudo sysctl --system - 設定を確認します。
sysctl net.mptcp.enabled
3.3. 修正カーネルの適用
- パッケージ情報を更新します。
sudo apt update - カーネルパッケージの更新候補を確認します。
apt-cache policy linux-generic linux-image-generic - 修正済みパッケージが提供されている場合、更新します。
sudo apt install --only-upgrade linux-generic linux-image-generic - OSを再起動します。
sudo reboot - 稼働カーネルを確認します。
uname -r
以上です。
なお、手順5～8はMPTCPを使用していない環境での暫定対応です。
MPTCPの無効化だけでは、今回の脆弱性への対処は完了しません。
また、手順11以降は修正済みカーネルが提供されてから実施します。
4. 詳細手順
4.1. 現在のカーネルを確認
まずは、稼働中のカーネルを確認します。
uname -rここで表示されたバージョンを控えておきます。
続いて、インストール済みのカーネルパッケージを確認します。
dpkg -l | grep linux-image現在使用しているカーネルと、インストール済みのカーネルを把握しておきます。
特に、更新後に問題が発生した場合、旧カーネルで起動できる状態かどうかは重要です。
4.2. MPTCPの使用状況を確認
MPTCP（Multipath TCP）は、複数のネットワーク経路を利用して1つのTCP通信を構成するための拡張プロトコルです。
例えば、Wi-Fiとモバイル回線を併用し、通信経路を切り替えながら接続を維持するような用途で使用されます。
Linuxでは、次のカーネルパラメータでMPTCPの有効・無効を制御できます。
net.mptcp.enabled現在の設定を確認します。
sysctl net.mptcp.enabled1：有効0：無効
続いて、MPTCPを使用している待ち受けソケットを確認します。
sudo ss -MlnpMPTCPを使用しているサービスが表示された場合は、そのサービスへの影響を確認します。
特に、Go 1.24以降では、Linux上の待ち受けソケットでMPTCPが利用される場合があります。
意図的にMPTCPを設定していなくても、アプリケーション側の実装によって利用されている可能性があるため、確認しておきます。
4.3. TCPリクエスト移行機能を確認
今回の脆弱性では、TCPリクエストソケットの移行処理にも類似した問題があります。
この機能に関係するカーネルパラメータが、以下のものです。
net.ipv4.tcp_migrate_req設定を確認します。
sysctl net.ipv4.tcp_migrate_req通常は0です。
1になっている場合は、TCPリクエスト移行機能を使用している可能性があります。
この機能を意図的に有効化している場合は、使用目的を確認したうえで対応を検討します。
5. 暫定対応：MPTCPの無効化
修正済みカーネルが提供されるまでの間、攻撃対象となる機能を減らす方法として、MPTCPの無効化があります。ただし、ここは少し注意が必要です。
今回の脆弱性の本体はIPv4 TCPのソケット処理にあります。MPTCPを無効化することで、MPTCPを利用した攻撃経路を制限することはできますが、通常のTCP処理に存在する脆弱性そのものが解消されるわけではありません。
また、Red Hatのセキュリティ情報では、この脆弱性に対して、同社の基準を満たす緩和策は提供されていないとされています。
そのため、MPTCPの無効化は、修正パッチが届くまでの攻撃対象領域を減らす措置として扱います。
5.1. MPTCPを無効化
MPTCPを使用していないことを確認したうえで、以下のコマンドを実行します。
sudo sysctl -w net.mptcp.enabled=0この設定は即時反映されます。MPTCPを使用しているサービスが存在する場合は、サービス側の再起動なども含めて確認が必要です。
5.2. 再起動後も設定を維持
sysctl -wによる設定変更は、OSを再起動すると元に戻ります。
再起動後も無効化した状態を維持する場合は、設定ファイルを作成します。
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf設定を反映します。
sudo sysctl --system最後に設定値を確認します。
sysctl net.mptcp.enabled以下のように表示されれば設定完了です。
net.mptcp.enabled = 05.3. 設定変更による影響
MPTCPを無効化した場合、影響を受けるのはMPTCPを利用する通信です。
一般的なWebサーバーやSSH、データベースなどで使用される通常のTCP通信は、そのまま利用できます。
| 対象 | 影響 |
|---|---|
| Apache / Nginx | 通常のTCP通信に影響なし |
| SSH | 通常のTCP通信に影響なし |
| MySQL / PostgreSQL | 通常のTCP通信に影響なし |
| MPTCP対応アプリケーション | MPTCPによる通信が利用できなくなる |
| マルチホーム環境 | MPTCPを利用した経路制御に影響 |
一般的なVPSやWebサーバーでは、MPTCPを意図的に利用しているケースは多くありません。
筆者のようにApacheを中心としてWebサービスを公開している環境であれば、通常のTCP通信に対する影響はありません。
ただし、Go製のアプリケーションなどがMPTCPを利用している可能性もあるため、使用状況を確認したうえで設定を変更します。
6. 根本対策：修正済みカーネルへの更新
今回の脆弱性はカーネル内部の処理に起因するため、根本的な対策は修正済みカーネルへの更新です。
Ubuntuでは、上流のLinuxカーネルで修正が公開されていても、Ubuntuの公式パッケージに反映されるまでには時間差があります。
また、Ubuntuでは修正内容が既存のカーネル系列にバックポートされることがあります。
そのため、単純にuname -rの数字だけで修正済みかどうかを判断するのではなく、Ubuntu Security Trackerで対象パッケージの修正状況を確認します。
6.1. パッケージ情報を更新
sudo apt update続いて、カーネルパッケージの候補を確認します。
apt-cache policy linux-generic linux-image-generic修正済みパッケージが提供されていることを確認してから、更新作業に進みます。
6.2. カーネルパッケージを更新
Ubuntu 24.04 LTSの標準的なGenericカーネルを使用している場合は、以下のコマンドで更新します。
sudo apt install --only-upgrade linux-generic linux-image-generic更新時には、インストール対象となるパッケージとバージョンを確認します。
なお、HWEカーネルやクラウド向けカーネルなどを使用している場合は、対象となるパッケージが異なります。
その場合は、現在使用しているカーネル系列に対応したパッケージを更新します。
6.3. OSを再起動
カーネルパッケージの更新が完了したら、OSを再起動します。
sudo rebootこの操作によって、サーバー上で稼働しているサービスは一時的に停止します。
事前に確保した作業時間内で実施します。
6.4. 更新後の確認
再起動後、稼働カーネルを確認します。
uname -r続いて、インストール済みのカーネルパッケージを確認します。
dpkg -l | grep linux-imageUbuntu Security Trackerで確認した修正済みパッケージが適用されていることを確認します。また、ApacheやSSHなど、サーバー上で稼働しているサービスについても動作確認を行います。
7. 切り戻し
設定変更後に問題が発生した場合に備え、切り戻し方法もまとめておきます。
7.1. MPTCPの設定を元に戻す
まずは、設定ファイルを削除します。
sudo rm /etc/sysctl.d/99-disable-mptcp.conf続いて、MPTCPを有効化します。
sudo sysctl -w net.mptcp.enabled=1設定を確認します。
sysctl net.mptcp.enabled以下のように表示されれば設定完了です。
net.mptcp.enabled = 1なお、この手順は変更前の設定が1だった場合のものです。変更前から0だった場合は、その状態を維持します。
また、既存のMPTCPソケットについては、必要に応じてサービスの再起動を行います。
7.2. カーネル更新後に問題が発生した場合
カーネル更新後にOSが正常起動しない場合は、GRUBから旧カーネルを選択して起動します。
VPSの場合は、管理コンソールなどから復旧操作を行います。そのため、作業前には以下を確認しておきます。
- 旧カーネルが残っていること
- 管理コンソールから操作できること
- 必要なバックアップが取得されていること
特に、SSHでしか接続できない環境では、再起動後にネットワークが利用できなくなると復旧が難しくなります。
このあたりは、フェイズゼロで確認しておくべき項目です。
おわりに
今回のCVE-2026-98432は、LinuxカーネルのIPv4 TCP処理に存在するUse-After-Freeの脆弱性です。
対応としては、
- 現在のカーネルと修正パッケージの提供状況を確認する
- MPTCPを使用していなければ、暫定的な無効化を検討する
- 修正済みカーネルが提供され次第、更新と再起動を実施する
という流れになります。
そして、今回改めて意識したのは、技術的な対応そのものよりも、その作業時間をどう確保するかという点です。カーネルの更新は、コマンドだけを見れば難しい作業ではありません。
しかし、組織で運用しているサーバーの場合、OSの再起動というだけで相応の調整が必要になります。
そこで「業務に影響があるから」という理由だけで更新を先送りするのであれば、脆弱性を放置することで発生するリスクも、同じように評価する必要があります。
未来を完全に予測することはできなくても、未来に向けて判断できる状態を維持することはできます。
そのためにも、今回のような脆弱性への対応では、技術的な対策と同じぐらい、迅速に判断して実行できる環境を整えておきたいところです。
コメントを残す