CVE-2026-98432は、LinuxカーネルのIPv4 TCP接続確立処理に存在するUse-After-Free脆弱性である。細工した通信を送れるリモートの未認証攻撃者が、TCPのSYN処理で競合状態を起こし、解放済みメモリをカーネルに参照させる可能性がある。現実的に最も懸念される影響はカーネルクラッシュによるサービス拒否（DoS）で、メモリ破壊につながる理論上の余地もある。
ただし、「インターネットから到達可能なLinuxは直ちに乗っ取られる」という意味ではない。競合を成立させる必要があり攻撃の複雑度は高い。2026年10月29日時点で、主要Linuxベンダーの一次情報には実環境での悪用や、機密性・完全性への影響が実証されたとの記載は見当たらない。それでも、認証前に到達できるカーネルのネットワーク処理が対象であるため、外部公開するIPv4 TCPサーバは優先して更新すべきである。
最初に結論
- 対象はLinuxカーネルのIPv4 TCP処理。Web、API、リバースプロキシ、メールなど、外部から到達できるTCP待受が評価対象になる。
- 原因は、SYN要求に付随するIPv4オプションのメモリを別処理へ引き渡す際、RCU読者が残っている可能性を考慮せず即時解放していたことにある。
- 上流の修正は、即時解放の
kfree()を、RCUの猶予期間後に解放するkfree_rcu()へ変更するもの。 - 上流安定版では5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3以降が修正済みの目安。ただし、ディストリビューションは古い版へバックポートするため、版番号だけで判定してはいけない。
- Debian、Amazon Linuxの一部、Oracle Linuxなどは修正を公開済み。Red HatとUbuntuは本稿執筆時点で未修正または対応中の製品が多い。
- 更新パッケージを入れただけでは、再起動まで古いカーネルが動き続ける。更新後は再起動し、実行中カーネルを確認する。
何が起きる脆弱性なのか
TCPサーバがSYNを受け取ると、Linuxは接続が完全に成立する前の状態をrequest socketで管理する。IPv4オプションが付いたSYNでは、その情報をireq->ireq_optが指す。接続が成立すると、tcp_v4_syn_recv_sock()はこのポインタを新しい子ソケットのinet_optへ移す。
問題は、このデータを別CPUが同時に読んでいる可能性があることだ。同じ接続に対する再送SYNを別CPUが処理すると、SYN/ACKを組み立てるip_options_build()が、RCUの保護下でIPv4オプションを読むことがある。その最中に子ソケットが破棄され、inet_sock_destruct()が通常のkfree()でメモリを直ちに解放すると、別CPUは解放済み領域を参照してしまう。
CPU 0: 再送SYNを処理 CPU 1: 子ソケットを破棄
RCU read lock
ireq_optを参照 ───────────────┐
├─ kfree(ireq_opt)
ip_options_build()で使用 <────┘ 解放済みメモリを参照
RCU read unlockこの競合がUse-After-Freeである。解放後の領域が再利用されるタイミング次第で、無効な値の読み出し、カーネルメモリ破壊、クラッシュにつながり得る。
もう一つの経路 ― request socketの移行
同じ所有権の不整合は、request socketを別のリスニングソケットへ移す経路でも起こる。net.ipv4.tcp_migrate_req=1、またはBPFのBPF_SK_REUSEPORT_SELECT_OR_MIGRATEを利用する構成では、古いrequest socketと複製先が同じireq_optを共有し、一方が解放した後でもう一方が参照する可能性がある。
ただし、移行機能を無効にすれば完全に回避できるわけではない。再送SYNと子ソケット破棄の競合は、移行機能とは別の主要経路だからだ。tcp_migrate_req=0は該当する追加経路を閉じるだけで、CVE全体の緩和策にはならない。
なぜkfree_rcu()で直るのか
RCU（Read-Copy-Update）は、読み取り側を軽量に保ちながら、古いデータの解放を安全な時点まで遅らせるLinuxカーネルの仕組みである。読み手がRCUのクリティカルセクション内にいる間、書き手はポインタを切り替えられるが、古い実体をすぐに解放してはいけない。
上流コミットe3f33b0a1d89は、inet_sock_destruct()とtcp_v4_reqsk_destructor()にあるIPv4オプションの解放をkfree_rcu()へ変更した。これにより、変更前から参照していた全RCU読者が処理を終える猶予期間を待ってから実メモリを解放する。読者側を大きく作り直すのではなく、既存のRCU契約に解放側を合わせた修正である。
IPv6は影響を受けるのか
今回の主要なIPv4経路と同じ問題は、通常のIPv6接続生成処理にはない。tcp_v6_syn_recv_sock()はオプションを複製してから子ソケットへ渡すためである。一方、request socket移行時にIPv6オプションを扱う別の問題があり、上流の修正説明ではCALIPSOを使用する場合の追加修正が別パッチになるとされている。
したがって「IPv6に切り替えればすべて解決」とは判断しない方がよい。今回のCVEの中心はIPv4だが、運用上は使用機能とベンダーの修正範囲を確認すべきである。
CVSS 9.8と5.9が併存する理由
CVEの公開記録やUbuntuはCVSS 3.1で9.8相当、Red Hatは5.9（Moderate）、OracleとSUSEは8.1相当としており、評価に幅がある。これは脆弱性の正体が異なるのではなく、メモリ破壊が機密性・完全性へ及ぼす可能性をどう評価するかが違うためだ。
Red Hatは、攻撃者がリモート・未認証で到達できる一方、競合の成立には高い複雑度が必要で、確認できる主な影響を可用性低下としている。この前提では機密性・完全性を0と評価し5.9になる。対して、カーネルのUse-After-Freeが任意コード実行へ発展し得る最悪ケースまで含めると9.8に近づく。
運用判断では点数だけを比較せず、未認証のネットワーク境界にあること、実害としてDoSが成立し得ること、カーネル障害であることを重視する。外部公開サーバ、ロードバランサ配下の多数ノード、停止影響の大きい基盤は優先度を上げるべきである。
上流Linuxカーネルの修正状況
修正はLinux 7.3-rc7へ取り込まれ、各安定版系列へバックポートされた。OSVが示す最初の修正版は次のとおりである。
| 上流系列 | 最初の修正版 | 判定 |
|---|---|---|
| 5.10.y | 5.10.272 | 以降は修正済み |
| 5.15.y | 5.15.223 | 以降は修正済み |
| 6.1.y | 6.1.190 | 以降は修正済み |
| 6.6.y | 6.6.159 | 以降は修正済み |
| 6.12.y | 6.12.113 | 以降は修正済み |
| 6.18.y | 6.18.56 | 以降は修正済み |
| 7.2.y | 7.2.10 | 以降は修正済み |
| メインライン | 7.3 | 修正済み |
これは上流カーネルだけを見た目安である。RHEL、Ubuntu、Debianなどは同じ修正を独自のパッケージへバックポートするため、「6.8だから未修正」「6.1だから安全」とは判定できない。必ずディストリビューションのCVEページとパッケージリリース番号を照合する。
ディストリビューション別パッチ状況
以下は2026年10月29日時点の各社一次情報を整理したもの。状態は随時変わるため、実際の更新前にリンク先で再確認してほしい。
| 製品／系列 | 現在の状況 | 注意点 |
|---|---|---|
| Red Hat Enterprise Linux 10 / 9 / 8 | 影響あり・修正未公開 | 通常版とRT、RHCOSノードなどが対象。Red Hatは修正を将来の更新へ延期としている。RHEL 7は影響なし。 |
| Ubuntu 26.10 / 26.04 LTS / 24.04 LTS / 22.04 LTS | 脆弱・対応中 | 通常カーネルの予定版は順に7.3.0-10.10、7.0.0-43.43、6.8.0-149.149、5.15.0-203.213。20.04以前や各クラウド用flavorも個別確認が必要。 |
| Debian 13 trixie | 修正済み | securityリポジトリの6.12.113-1。DSA-6568-1で公開。通常側6.12.107-1は脆弱と記録されている。 |
| Debian 12 bookworm | 修正済み | securityリポジトリの6.1.190-1。通常側6.1.176-1は脆弱と記録されている。 |
| Debian forky / sid | 修正済み | それぞれ7.2.12-1、7.2.13-1。 |
| Amazon Linux 2023 kernel6.12 | 修正済み | ALAS2023-2026-3335、2026年10月29日公開。 |
| Amazon Linux 2023 kernel6.18 | 修正済み | ALAS2023-2026-3251、2026年10月24日公開。 |
| Amazon Linux 2、AL2023既定kernelなど | 修正待ち | AL2のcoreと5.4／5.10／5.15 extras、AL2023の既定kernelはPending Fix。 |
| Oracle Linux 7〜10 UEK | 修正済み | ELSA-2026-500397、500398、500399を2026年10月16日に公開。利用中UEKと対象アドバイザリを照合する。 |
| SUSE / openSUSE | 一部修正、全体は対応中 | SUSE Linux Micro 6.2とopenSUSE Leap 16.0は6.12.0-160000.40.1以降が修正済み。ほかの製品はPending／In progressを含む。 |
| Fedora 43 / 44 / 45 | 公開版番号上は修正範囲 | 公開パッケージは7.2.13、7.2.13、7.2.11で、上流7.2.10以降に該当する。この行は版番号からの推定であり、Fedora固有のCVE判定を優先する。 |
| Arch Linux | 公開版番号上は修正範囲 | linux 7.2.11.arch1-1は上流7.2.10以降に該当する。インストール済み版と起動中版を確認する。 |
自分のサーバを確認する
1. OS、パッケージ、実行中カーネルを記録する
cat /etc/os-release
uname -r
uname -vuname -rが示すのは今動いているカーネルである。パッケージ管理画面に新しいカーネルが見えても、再起動していなければ古い版のままになる。Ubuntuやクラウド環境ではlinux-aws、linux-azure、linux-gcpなどflavorごとに修正状況が違うため、パッケージ名も記録する。
2. IPv4 TCPの公開面を棚卸しする
ss -lntp
sysctl net.ipv4.tcp_migrate_reqssの結果だけでなく、クラウドファイアウォール、NAT、ロードバランサ、KubernetesのServiceやIngressも確認する。127.0.0.1だけで待ち受けるサービスと、インターネットから到達できる0.0.0.0待受では優先度が異なる。tcp_migrate_reqが1なら追加の競合経路を使用し得るが、0でも主要経路の影響は残る。
3. ベンダー提供パッケージを適用して再起動する
# Debian / Ubuntu系の例
sudo apt update
sudo apt full-upgrade
sudo reboot
# RHEL / Fedora系の例
sudo dnf upgrade --refresh
sudo reboot本番環境では、冗長構成から1台ずつ切り離して更新し、再起動後にuname -r、待受ポート、ヘルスチェック、アプリケーションログを確認する。自前ビルドや出所不明のカーネルへ置き換えるより、ベンダーがサポートする更新を待つ方が安全である。
パッチがまだない環境での暫定対応
Red Hatは、性能や機能への大きな影響なしに広く適用できる実用的な緩和策はないとしている。設定変更を「修正済み」と扱わず、次の措置で露出と障害影響を下げる。
- 不要なIPv4 TCP待受を停止し、管理画面や内部APIをVPN、踏み台、許可IPだけへ制限する。
- 上流のファイアウォールやロードバランサで異常なSYN流量を監視し、必要に応じてレート制限する。ただし通常通信を巻き込む可能性があり、脆弱性そのものを消す対策ではない。
- 単一ノードの停止がサービス全体の停止にならないよう、冗長化と切り替え手順を確認する。
- カーネル更新を即時適用できるメンテナンス枠、再起動手順、ロールバック手段を先に用意する。
- ベンダーのCVEページとセキュリティリポジトリを継続監視する。
検知と事後確認
次のコマンドでカーネルログを確認する。ip_options_build、tcp_v4_send_synack、inet_sock_destructを含むスタックトレース、slabのUse-After-Free、予期しないカーネルパニックは調査対象になる。
sudo journalctl -k --since "2026-10-01"
sudo dmesg -T | grep -Ei 'use-after-free|KASAN|BUG:|panic|ip_options_build|tcp_v4|inet_sock_destruct'ログがないことは安全の証明ではない。通常の本番カーネルではKASANが無効で、異常が別のクラッシュとして現れたり、ログが再起動で失われたりする可能性がある。集中ログとクラッシュダンプを利用している場合は、保持期間と収集状態も確認する。
運用者が避けたい誤判断
- 「CVSS 5.9だから後回し」 ― 外部公開・未認証のカーネル攻撃面であり、停止影響が大きいシステムでは優先度が上がる。
- 「CVSS 9.8だからリモートrootが実証済み」 ― 最悪影響を表す評価と、確認済みの実攻撃・再現結果は別である。
- 「カーネル6.1なら安全」 ― 修正済みなのは上流6.1.190以降。さらにディストリビューションのバックポート有無を確認する必要がある。
- 「パッケージを更新したので完了」 ― 再起動前は脆弱な旧カーネルが動き続ける。
- 「
tcp_migrate_req=0で回避できる」 ― 移行経路は閉じられても、再送SYNによる主要経路は残る。
情報源
- Linux kernel: net/ipv4: defer freeing IP options until after an RCU grace period
- OSV: CVE-2026-98432
- Red Hat Product Security: CVE-2026-98432
- Ubuntu Security: CVE-2026-98432
- Debian Security Tracker: CVE-2026-98432
- Debian Security Advisory DSA-6568-1
- Amazon Linux Security Center: CVE-2026-98432
- Oracle Linux: CVE-2026-98432
- SUSE: CVE-2026-98432
- Fedora Packages: kernel-core
- Arch Linux Security Tracker: linux
本記事は2026年10月29日時点の公開情報に基づく。パッチ状況は短期間で変わるため、対応時には利用中ディストリビューションの公式CVEページと更新リポジトリを必ず確認してほしい。