CVE-2026-98432とは？Linux・Ubuntuの影響範囲と修正状況の確認方法

CVE-2026-98432は、LinuxカーネルのIPv4/TCP接続処理に見つかった、解放済みメモリを参照する「use-after-free（UAF）」の脆弱性です。ネットワーク上の特定の競合状態によってカーネルがクラッシュし、サービス停止（DoS）につながる可能性があります。2026年10月30日時点で、上流Linuxカーネルには修正が取り込まれている一方、Ubuntuの公式情報では複数のリリース・カーネルパッケージが依然として「Vulnerable（影響あり）」と表示されています。まず使用中のカーネルを確認し、Ubuntuの対象パッケージ欄で修正状況を照合することが重要です。

この脆弱性の告知日は2026年10月15日です。UbuntuのUbuntu公式のCVE-2026-98432情報には「最終更新：2026年10月26日」と記載されています。以下の状況は記事確認時点のものであり、その後のパッケージ公開によって変わる可能性があります。

CVE-2026-98432とは何か

問題は、TCP接続確立時に使用するIPv4のソケットオプションを、別のCPUがまだ参照している間に解放してしまう可能性があることです。再送されたSYNへの応答や、リクエストソケットの移行が並行して発生すると、参照側が解放済み領域にアクセスする競合が生じます。影響する上流コードは主にnet/ipv4/af_inet.cとnet/ipv4/tcp_ipv4.cです。

公開情報から想定される実務上の主なリスクは、外部から到達可能なTCPサービスを通じたカーネルの異常終了と可用性の低下です。攻撃にはタイミング依存の競合を成立させる必要があり、公開されたスコアだけを根拠に「誰でも確実に遠隔コード実行できる」と判断すべきではありません。Red HatはDoSを現実的な主な影響として説明しています。詳細はRed Hatの製品別評価とLinuxカーネルのCVE告知原文で確認できます。

深刻度の数字が異なる理由

UbuntuのページにはCVSS v3.1で9.8（Critical）、CVSS v4.0で8.3（High）が掲載されています。一方、Red Hatは同社製品についてCVSS v3.1で5.9（Moderate）と評価しています。評価者ごとに、攻撃の難しさ、想定する影響、製品の実装や運用条件が異なるためです。単一の点数だけで対応要否を決めず、ネットワーク公開状況と対象カーネルを優先して確認してください。

Linuxのどのバージョンが影響を受ける？

LinuxカーネルのCVE告知では、この問題を導入したコミットがLinux 4.4系列に含まれ、その後の系列で修正されたとされています。告知に記載された主な修正版は次のとおりです。

これは上流カーネルの修正履歴であり、Ubuntuや他のディストリビューションの「修正済みパッケージ番号」を意味するものではありません。配布元は独自にパッチをバックポートするため、uname -rで表示される数字が表の数字より小さくても、修正済みの場合があります。逆に、数字が近いというだけでは安全性を判定できません。修正コミットの例は6.12系の修正コミットで参照できます。

Ubuntuの影響範囲と更新状況

Ubuntuの公式CVEページで、通常のlinuxパッケージに表示されていた状態を抜粋すると、次のようになります（2026年10月26日更新の掲載内容を、10月30日に確認）。

ここでの「修正作業中」は、Ubuntuの表示「Vulnerable work in progress」を意味し、「修正版がすでに一般提供されている」という意味ではありません。Canonicalはlinux-aws、linux-gcp、linux-azure、linux-kvmなど、多数のカーネル系統を別の行で管理しています。クラウド環境、低遅延カーネル、FIPS版、Ubuntu Proの保守対象は一律ではないため、Ubuntuのバージョンだけで判断せず、使用中のパッケージ名まで一致させてください。最新の判定はUbuntu公式のCVE-2026-98432情報を参照してください。

自分のUbuntuが対象か確認する方法

1. OSと実行中のカーネルを調べる

Ubuntuの端末を開き、次のコマンドを実行します。

cat /etc/os-release
uname -r

VERSION_IDやPRETTY_NAMEでリリースを、uname -rで現在稼働しているカーネルを把握できます。後者に-aws、-azure、-gcp、-genericなどの文字列があれば、パッケージ種別を確認する手掛かりになります。

2. インストール済みパッケージと公式の「Status」を照合する

dpkg -l 'linux-image*'
apt list --upgradable

インストール済みのカーネルイメージと、更新候補の有無を確認します。dpkgの一覧には過去のカーネルも表示されるため、まずuname -rと一致する実行中のものを特定してください。その上でUbuntu公式のCVE-2026-98432情報の「Package」「Ubuntu Release」「Status」を照合します。アップグレード候補が表示されないことは、脆弱性が修正済みであることの証明にはなりません。

3. 修正が提供されたら正規の更新経路で適用する

Canonicalが修正済みパッケージを公開したら、バックアップとメンテナンス時間を確保した上で、通常のAPT更新を行います。

sudo apt update
sudo apt upgrade

更新内容と依存関係を確認し、必要なら再起動します。再起動が必要かどうかは/run/reboot-requiredの有無も手掛かりになります。更新後はuname -rで新しいカーネルが起動しているか確かめ、公式ページの修正済みパッケージ情報と再照合してください。手順の根拠はUbuntuのCVEと更新方法の説明とUbuntuのセキュリティ更新に関する公式文書です。

パッチがまだない場合の対処と注意点

• 外部公開範囲を確認する：不要なTCP待ち受けポートを閉じ、ファイアウォールやネットワークアクセス制御で到達元を必要最小限に絞ります。これは一般的なリスク低減策で、脆弱性そのものを修正するものではありません。
• ベンダーの更新通知を追跡する：Ubuntu Security Notices、CVEページ、利用中のクラウド提供元のメンテナンス案内を確認します。パッケージ名とビルド番号が合う更新を待って適用します。
• Livepatchを過信しない：Ubuntu ProのLivepatchが有効でも、すべてのCVEが対象になるわけではありません。このCVEに対応したLivepatchが提供されているかは別途確認が必要です。カーネル更新に再起動が必要な場合もあります。Livepatchと再起動の公式説明を参照してください。
• 修正コミットを単独適用しない：上流LinuxとCanonicalはいずれも、個別の修正を安易に抜き出して適用することを推奨していません。原則として配布元が検証したパッケージを使用します。

確認時に間違えやすいポイント

「IPv6なら完全に無関係」ではありません。公式の説明によれば主要なIPv4の問題はIPv6側の実装とは異なりますが、IPv6のリクエストソケット移行には別の関連する問題が示されています。また、「上流カーネルで修正済み」と「手元のUbuntuに修正が届いた」は別の事実です。運用中のホストが公開TCPサービスを持つか、使用パッケージに修正が配信されたか、更新後のカーネルが起動しているかを順番に確認してください。

確認先を一つに絞るなら、Ubuntu利用者はまずUbuntu公式のCVE-2026-98432情報です。CVE番号の登録内容や変更履歴はCVE Programの公開記録、技術的な修正内容はLinuxカーネルのCVE告知原文で追跡できます。修正状況は変わるため、この記事の表より公式ページの最新表示を優先してください。