CVE-2026-98432は、Linuxカーネルの通信処理で解放済みメモリーを参照する脆弱性です。Red Hatは10月30日の緊急情報でCriticalとし、修正提供を急いでいます。上流の修正版と、自社が使うOSの修正パッケージは別です。「更新はありません」という表示だけでは対応完了と判断できません。
Webサイト、API、メール、社内サービスなどを支えるLinuxで、アプリケーションより下の層にある通信処理の脆弱性が問題になっています。対象はCVE-2026-98432。認証前のTCP接続を扱うため、アプリのログインを強化するだけでは修正になりません。
Red Hatの緊急情報RHSB-2026-016は10月30日に公表され、調査継続中としています。Akamai／Linodeのステータスページにも同日18:10 UTC（日本時間10月31日3:10）に調査開始、21:18 UTC（同6:18）に継続中の報告が掲載されました。これはクラウド事業者の調査状況であり、利用者のサーバーがすでに修正済み、または侵害済みだという意味ではありません。
本記事の確認は2026年10月31日7時台（日本時間）です。CVE自体の初公表は10月15日で、約16日前。今回の新情報は10月30日のベンダー対応と最新の修正状況です。新しく見つかった脆弱性として日付を言い換えず、今行う点検に絞って説明します。実機での攻撃再現や本番設定の変更は行っていません。
原因を図解するように読む：まだ使っているメモリーを片付けてしまう
TCPは、相手と接続を確立してデータをやり取りする通信方式です。接続準備の情報を処理する間に、複数のCPUが同じ情報へ並行してアクセスすることがあります。今回の問題は、片方の処理が情報を使い終えてメモリーを解放したあとも、もう片方がその場所を読んだり使ったりしてしまうことです。これをuse-after-free（解放後の使用）と呼びます。
| 処理の流れ（説明用の概念） | 起こり得ること |
|---|---|
| 接続要求を受けてIPv4オプションを保存する | 複数の処理が同じ情報を参照する |
| 接続の処理が進み、一方が情報を解放する | もう一方の処理が終わる前にメモリーの寿命が切れる |
| 並行する処理がその情報を使い続ける | カーネルの異常終了やメモリー破壊につながる |
| 修正で解放の時点を適切に遅らせる | 参照中の処理が終わるまで待ってから片付ける |
Linuxカーネルチームの説明では、再送された接続要求を扱う経路と、接続要求のソケットを移す経路が説明されています。ソケットは通信の状態を扱う仕組みです。特定の移行設定を無効にしただけで、別の経路までなくなるとは判断できません。上の表は仕組みを理解するための整理で、攻撃手順や実測結果ではありません。
Red Hatの緊急情報は、未認証の遠隔攻撃者によるコード実行の可能性を説明しています。一方、安定してコードを実行できる条件と、システムが停止する条件は同じではありません。「すべてのLinuxが即座に乗っ取られる」とは言えませんが、停止だけでも受注や業務接続に影響するため、外部からTCP接続を受ける重要なサーバーを先に調べます。
重大度、実悪用、対象条件を分けて記録する
| 項目 | 確認できた内容 |
|---|---|
| 識別子 | CVE-2026-98432。LinuxカーネルのIPv4 TCP処理 |
| Linuxカーネルチームの評価 | CVSS v3.1：9.8、Critical |
| Red HatのWeb情報 | CVEページはCVSS v3.1：9.8。緊急情報もCritical |
| Ubuntuの表示 | CVSS 3：9.8、Critical。Ubuntu独自の優先度はHigh |
| 前提 | 影響するカーネルを使用。IPv4のTCP接続を受けるシステムを優先点検 |
| 実悪用 | 今回確認した一次資料では実際の悪用事例を確認していない。安全の証明にはならない |
評価の出典はカーネルチーム、Red HatのCVEページ、UbuntuのCVEページです。なお、確認時点のRed Hat公開JSONには8.1／Importantが残り、Webページの9.8／Criticalと一致していませんでした。単一の数値を全情報源に当てはめず、取得元と時刻を残し、本記事は10月30日の緊急情報を優先しています。
同時点のCISA KEV公式データでは、このCVEの掲載を確認しませんでした。KEVは実悪用が確認された脆弱性を集めたものですが、未掲載だから悪用されていないと断定できるわけではありません。コード実行の可能性、検証コードの存在、実際の被害は分けて判断します。
IPv6なら全て安全という説明も避けます。カーネルチームは最初の問題についてIPv6では処理が異なると説明する一方、CALIPSOというIPv6のセキュリティラベル機能に関わる移行処理の問題を別パッチで扱うと説明しています。業務への影響を無視してIPv4を止めることを、この記事の万能な回避策にはしません。
修正版の見方：上流カーネルとOSの配布パッケージは別
カーネルチームの修正情報は、問題が4.4で入ったことと、以下の修正済み版を記載しています。これは上流の系列ごとの情報です。配布元が古い版へ修正を取り込むバックポートを行う場合、見かけのカーネル番号だけでは判断できません。
| 上流カーネルの系列 | このCVEの修正済み版として記載 |
|---|---|
| 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 |
表にない系列を安全とは判断できません。また、企業向けOSのカーネルをこの表だけ見て独自ビルドへ置き換えることも勧めません。ベンダーがサポートする更新経路、ドライバー、監視・バックアップ製品との互換性を確認します。上流修正の取り込みと、利用中のOS向けパッケージの提供開始は別の日になることがあります。
| 配布元・対象 | 10月31日7時台の確認結果 | 担当者が次に見るもの |
|---|---|---|
| Ubuntuのlinuxパッケージ：26.10／26.04／24.04／22.04 | Vulnerable、work in progress。予定版の記載は提供済みを意味しない | CVEページの該当するOS・パッケージ行と、正式な修正公開 |
| Ubuntu：20.04のlinux、HWE・クラウド向けなど | 20.04のlinuxはVulnerable。他の系列は別行で管理 | linux-hwe、linux-aws、linux-azureなど実際の配布系列と保守契約 |
| RHEL 8／9／10、OpenShift等 | 緊急情報の対象。修正提供を急いでいると説明。取得した公開JSONにはaffected_release項目がなく、修正リリースを確認できず | 最新の緊急情報、製品・保守系列ごとのErrataとパッケージ |
| クラウド上の自分で管理するLinux VM | クラウド全体の告知だけではゲストOSの修正完了を判断できない | ゲストOSの担当者、配布元、更新・再起動の実施状況 |
Ubuntu表の根拠は公式CVEページです。同じUbuntuでも標準カーネル、HWE、AWS向けなどで行が違います。「Not in release」はその組み合わせでパッケージが提供されないという表示であり、別系列で動く自分のサーバーが安全という意味ではありません。RHELは緊急情報と公開JSONを併せて確認しました。配布状況は変わるため、実際の作業直前に再確認してください。
更新前にできることと、暫定策の限界
Red Hatは緊急情報のMitigation欄に、IPv4のIPオプションを含むTCPパケットをnftablesで落とす手順を示しています。ただし同社は、露出を減らしても完全な防止にはならず、必要な通信に影響する可能性があると明記しています。修正カーネルへの更新の代わりにはできません。
IPオプションとTCPオプションは別のヘッダーにある情報です。名称が似ているからといってTCPオプションを一律に遮断するルールへ読み替えないでください。既存ファイアウォール、コンテナのネットワーク、転送経路なども考慮し、公式のルールを非本番環境で確認してから変更管理に従います。ここでは設定変更を自動実行するコマンドは配布しません。
- 不要な公開サービスを洗い出し、必要な接続元だけに制限できるかを担当者と検討する。これだけで完全に防げるとは扱わない。
- 更新がまだ提供されていない資産にも担当者と次の確認期限を付ける。「保留」のまま放置しない。
- 監視では停止・再起動の増加を確認するが、その事象だけでこのCVEの悪用と断定しない。記録を保全して調査する。
- ライブパッチなどを使っていても、サービスが契約済みという事実と、このCVEの修正が適用済みという証拠は分ける。
運用担当者の手順：調査から再起動後の確認まで
- 1対象を整理する。物理サーバー、VM、コンテナホスト、Kubernetesノード、委託先運用を資産IDで並べ、IPv4 TCPの到達範囲と止まる業務を記録する。
- 2OS名・リリース・稼働カーネル・パッケージの完全な版を確認する。コンテナ内のOS表示をホストOSの版として扱わない。
- 3配布元のCVEページと修正勧告を照合する。修正を含むパッケージが未提供なら、適用済みにせず未対応として期限を管理する。
- 4更新が提供されたら、バックアップ、停止時間、クラスタの冗長性、管理用の代替経路、失敗時の復旧方法を決める。
- 5承認済み手順で更新し、通常のカーネル更新では再起動後に稼働版を確認する。ライブパッチを使う場合は製品がこのCVEをカバーするかと実適用状況を確認する。
- 6通常の業務通信、監視、バックアップ、再起動後のサービスを確認する。攻撃コードを流して確かめない。
- 7配布元の修正根拠、実稼働の証拠、確認日時を残す。暫定策の解除も影響を確認し、残件を次の担当者へ渡す。
管理権限のあるLinuxホストでの最初の読み取り専用確認として、OS情報は「cat /etc/os-release」、稼働カーネルは「uname -r」が使えます。これだけで脆弱性の有無を判定することはできません。パッケージ管理情報や修正勧告との照合が必要です。この記事の制作環境はMacのため、対象Linuxでの実行結果を実測として掲載していません。
一般利用者は、利用しているサービスの保守案内と障害連絡先を確認してください。自分のブラウザーを更新しただけで、相手側Linuxのカーネル修正が完了するわけではありません。委託している場合は「このCVEに対する対象範囲、修正根拠、適用と再起動の確認」を運用会社へ確認するのが具体的です。
LLMに点検を手伝わせる：不明を安全に変換させない
空の点検台帳CSVを添付しました。自動診断ツールではなく手入力の記録表です。外部LLMへ渡す前に、資産IDは匿名化し、IPアドレス、内部ホスト名、認証情報、設定全文を除いてください。
私が管理権限を持つ資産の防御点検を補助してください。対象CVEはCVE-2026-98432です。添付した匿名化済み台帳と公式勧告のみを材料に、読み取り専用で整理してください。
出力は、資産ID、OSとカーネル系列、稼働版、完全なパッケージ版、IPv4 TCP到達範囲、対象判断、根拠URLと確認時刻、修正版の提供状況、適用状況、不足情報、担当者と期限の表にしてください。上流版とディストリビューションのバックポート、インストール済みと稼働中、コンテナとホストを区別してください。
work in progress、更新なし、KEV未掲載、ライブパッチ契約済みを「安全」「修正済み」に置き換えないでください。情報源の重大度が違う場合は出典と時点を並べ、不一致を残してください。情報が足りない資産は不明として追加確認を列挙してください。
更新計画には、公式修正根拠、提供待ちの再確認期限、停止影響、復旧方法、再起動またはライブパッチ適用の証拠、通常通信の確認、暫定策の残存リスクを含めてください。設定変更・更新・再起動・攻撃試験は実行せず、秘密値も要求しないでください。LLMの役割は台帳と根拠の整理です。実際の配備状態や安全を保証するものではありません。複数の勧告を同時に扱うときは、脆弱性の初動整理の考え方で、重要度と到達条件、対応の証拠をそろえてください。