ニュースの概要：LinuxのTCP処理に競合
LinuxカーネルのIPv4 TCP処理に、解放済みメモリを参照する「use-after-free」の脆弱性CVE-2026-98432が公表された。外部からTCPサービスへ到達できる攻撃者が、タイミングを調整した接続要求を送ることで競合状態を引き起こす可能性がある。カーネルが停止すれば、その上で動くサービスも止まる。2026年10月15日のLinuxカーネルCVEチームの告知を起点に、企業の管理者が対象を絞り込む方法を整理する。
引用元: CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period（Linux kernel CVE team、2026年10月15日）
何が起き、どの程度危険なのか
解放済みメモリを参照する競合
TCPの接続開始時、カーネルは接続要求とそのオプションを扱う。再送されたSYNの処理と別のCPUによるソケット破棄が重なると、片方がまだ読んでいるオプションのメモリをもう片方が解放してしまう場合がある。修正は、参照が終わるまで解放を遅らせるRCUの仕組みを用いる。要求ソケットの移行でも類似の問題がある。IPv6は主な問題では対象外だが、告知はCALIPSO利用時の移行に別の問題があるとも述べており、IPv6だけならすべて安全とは断言できない。
CVSS評価が異なる理由
CVSS v3.1の9.8は脆弱性の重大度の基本スコアで、観測された攻撃の発生率を表す数値ではない。Ubuntuも9.8を掲載する一方、Red Hatは攻撃の競合を成立させる難度を高いとし、機密性・完全性への影響は実証されていないとして5.9、主な実際上の影響をサービス停止と評価している。Amazon Linuxは7.0、Oracle Linuxは8.1と評価している。評価の差は前提の差であり、9.8だけで侵入や任意コード実行が実証されたと判断するのは早い。メモリ破損の可能性もあるため、公開サービスは優先して確認したい。
上流の修正版とベンダー版は分けて考える
Linuxカーネルチームの告知では問題の導入は上流4.4、修正は6.12.113、6.18.56、7.2.10、7.3-rc7の各系列とされる。これは上流の各系列の修正点であり、たとえば6.12より大きい番号なら一律に安全という意味ではない。ディストリビューションは古い番号のカーネルにも修正を移植するため、必ず利用中の製品・リリース・カーネルパッケージについてベンダーのCVE情報を照合する。
自分のサーバーが対象か：判定の手順
1. OSと稼働中のカーネルを確認
各ホストで次を実行し、OSの版と実際に動いているカーネルを記録する。コマンドは読み取り専用だ。コンテナ内のunameは共有するホストカーネルを示すため、コンテナイメージのOS名だけでは判定できない。仮想マシンはゲストOSごと、Kubernetesは各ノードについて確認する。
cat /etc/os-release
uname -r
Ubuntu/Debian系なら dpkg-query -W 'linux-image*'、RHEL/Amazon Linux系なら rpm -q kernel kernel-core で導入済みパッケージも確認できる。存在しないパッケージ名はエラーになる場合がある。インストール済みの新しい版とuname -rの稼働版が違えば、再起動前の古いカーネルが残っている可能性がある。
2. 製品別のCVE情報を照合
ベンダーのCVEページで、OSのリリースだけでなく、汎用・クラウド・HWE・リアルタイムなどのカーネル系列とパッケージの完全な版を確認する。2026年10月30日時点で、Ubuntuの状況表は複数の系列を脆弱または修正作業中と表示する。Red HatはRHEL 8・9・10などを影響あり、RHEL 7を影響なしと評価し、対象製品の修正は将来の更新に延期としている。Amazon LinuxではAL2023のkernel6.12とkernel6.18に修正済みの通知がある一方、ほかに修正待ちの系列がある。Oracle LinuxはUEK向けの修正通知を掲載している。状態は変わるため、適用時に再確認する。
判定は「ベンダーが対象か」「稼働中のパッケージに修正が入っているか」「修正版で起動しているか」を別々に記録する。パッケージ更新後でも再起動前は通常、旧カーネルが動き続ける。ライブパッチの適用を根拠にする場合も、このCVEと稼働版が対象かを提供元に確認する。独自ビルドやサポート切れのOSは上流の導入・修正コミットを管理者が追跡し、判断できなければ対象の可能性ありとして扱う。
3. 到達可能なTCPサービスを調べ、優先順位を決める
sudo ss -lntpで待ち受けポートとプロセスを確認し、IPv4のアドレスや0.0.0.0の待ち受けを調べる。IPv6のワイルドカード待ち受けがIPv4も受ける設定もあるため、表示だけで除外しない。クラウドのセキュリティグループ、ホストのファイアウォール、ロードバランサーやVPNを合わせて見て、インターネットや社内のどこから到達できるかを確認する。公開されていなくても内部ネットワークから到達できればリスクは残る。待ち受けの有無は優先順位の材料であり、脆弱性修正の有無を証明するものではない。
4. 更新、再起動、再確認
修正版が提供されていれば、各ベンダーの案内に従って対応するカーネルを更新する。業務影響と依存関係を確認し、冗長構成では順次切り替え、復旧手順と保守時間を確保して再起動する。再起動後はuname -rを再確認し、修正版のパッケージと一致すること、サービスの正常性を確認する。修正待ちなら不要な公開ポートの閉鎖、接続元制限、監視と復旧準備で露出を減らし、ベンダーの更新を追う。これらは修正の代替ではなく、Red Hatは広く適用できる正式な緩和策を示していない。
事業継続の観点で残すべき記録
資産台帳にOS・稼働カーネル・ベンダー判定・公開範囲・対応期限・再起動後の検証結果を残すと、担当者間で未対応と修正待ちを区別できる。外向きの重要サービスと複数のワークロードを支える共有ノードから着手し、停止時の切り替えや復旧時間も併せて点検したい。スコアの数字だけでなく、実際の到達性と業務への影響を重ねて判断することが、限られた保守時間を有効に使う鍵になる。