CVE-2026-98432 は、Linux カーネルの TCP 受け付け処理（SYN_RECV の経路）にある use-after-free です。CVSS 3.1 のスコアは 9.8（Critical）と高く、ネットワーク経由・権限不要・操作不要で機密性・完全性・可用性すべてに高い影響、と評価されています。2026年10月15日に Linux が CVE として公表しました。

ただし、この 9.8 という数字をそのまま「誰でもすぐリモートで乗っ取れる」と読むのは正確ではありません。実際に踏ませるには複数の条件が重なる必要があり、多くの場合はカーネルのクラッシュ（DoS）に留まります。カーネルのような基盤ソフトの脆弱性がどう伝わるかの全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。この記事は、何が起きるのか・9.8 の実際・自分のカーネルが該当するかの確かめ方を、一次情報で整理します。攻撃を再現する手順（PoC）は載せません。

WHAT HAPPENED何が起きるか

SYN_RECV の最中に、子ソケットが解放される

  1. 前提

    IP options 付きの SYN が届く

    request socket に ireq_opt（IP オプション）が載る。多くの経路では options は付かないため、ここが成立条件の一つ

  2. 所有権移動

    子ソケット生成で ireq_opt をコピーせず引き継ぐ

    tcp_v4_syn_recv_sock() が ireq->ireq_opt を newinet->inet_opt へ移す。複製しない

  3. 競合

    別 CPU が再送 SYN を処理し SYNACK を組む

    tcp_check_req() 経由で同じオプションを読む。listener ロックを持たないため子の解放を妨げない

  4. UAF

    子が kfree され、解放済みメモリを読む

    子ソケットは SOCK_RCU_FREE を持たず inet_opt を素の kfree() で解放。ip_options_build() で use-after-free

出典: CVE-2026-98432 公式記録（Linux 採番）とカーネルの修正コミット説明（2026-10-29 確認）。PoC は非掲載

30秒でわかる

  • ・CVE-2026-98432 は Linux カーネルの TCP SYN_RECV 経路の use-after-free。原因は request socket の IP オプション（ireq_opt）を子ソケットへコピーせず所有権だけ移すこと。
  • ・CVSS は 9.8 だが、実悪用には IP options 付きの SYN と、再送 SYN を別 CPU が並行処理する狭いレースが要る。多くはクラッシュ（DoS）止まりで、コード実行は高難度。
  • ・影響は 4.4 以降。修正は 5.10.272 / 5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 / 6.18.56 / 7.2.10、本流 7.3。
  • ・修正の本体は、解放を kfree_rcu（RCU 猶予後）へ変えること。IPv4 のみで、IPv6 は最初の問題の対象外。

時系列：CVE-2026-98432 で何が起きるか

問題は、TCP が接続を受け付ける途中の状態（request socket から子ソケットを作る瞬間）にあります。カーネルのコミット説明によると、tcp_v4_syn_recv_sock() は request socket が持つ IP オプション ireq->ireq_opt の所有権を、新しく作る子ソケット newinet->inet_opt へコピーせずに移します。

ここで別の CPU が、同じ request socket に対する再送 SYN を並行して処理し、tcp_check_req() から SYNACK を送ろうとすることがあります。SYNACK を組む tcp_v4_send_synack() や経路を引く inet_csk_route_req() は、ireq->ireq_opt を rcu_read_lock() の下だけで読み、さらに ip_options_build() が opt->optlen を二度読みます。

なぜ解放と読み取りがぶつかるのか

  • ・commit 079096f103fa（request socket を ehash テーブルに入れる変更、2016年頃）以降、request socket は listener のロックを持たずに処理される。だから SYNACK を組んでいる最中でも、子ソケットの解放を妨げるものが無い。
  • ・TCP の子ソケットは SOCK_RCU_FREE を持たず、inet_sock_destruct() は inet_opt を素の kfree() で即座に解放する。
  • ・結果として、別 CPU が解放済みの inet_opt を ip_options_build() で読む use-after-free が成立する。

なお、SYNACK タイマー自体は問題ではない、とコミットは明記しています。タイマーは request socket への参照を保持し、inet_csk_reqsk_queue_drop() が子の解放前に timer_delete_sync() を呼ぶためです。問題になるのは、ロックなしで並行処理される再送 SYN の経路です。

request socket の移行でも同じ問題が起きる

同種の問題が、request socket の「移行」（net.ipv4.tcp_migrate_req=1、または BPF_SK_REUSEPORT_SELECT_OR_MIGRATE プログラムを使う構成）でも起きます。reqsk_timer_handler() が inet_reqsk_clone() で request socket を複製すると、元とクローンが同じ ireq_opt を共有します。その後 reqsk_migrate_reset() が元のポインタをクリアしますが、元の request socket への参照を持つ別の CPU が、クローンの解放時にまだそのオプションを使っている（SYNACK を送る、あるいは tcp_v4_syn_recv_sock() で子を作る）ことがあります。ここでも tcp_v4_reqsk_destructor() が素の kfree() を使っていました。

つまり根っこは共通で、読み手は RCU を使っているのに、解放側が RCU の猶予を待たずに即 kfree していたというミスマッチです。do_ip_setsockopt() や cipso_v4_sock_setattr() のように inet_opt を差し替える他の経路は、すでに kfree_rcu() を使っていました。修正は、inet_sock_destruct() と tcp_v4_reqsk_destructor() でも同じく kfree_rcu() を使うことです。

CVSS 9.8 の実際：点数と現実の差

ここは落ち着いて読む価値があります。CVSS 3.1 ベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H で、スコアは 9.8。ネットワーク経由・低い攻撃条件・権限不要・利用者操作不要という「接続経路の広さ」が、この高い点数を作っています。

SCORE VS REALITY点数と実際

CVSS 9.8 は理論上の最悪値。実悪用には条件が重なる

スコアが示すこと

実際に必要な条件

スコアが示すこと: ネットワーク経由・権限不要・操作不要（AV:N/PR:N/UI:N）

実際に必要な条件: IP options 付きの SYN を届かせる（通常は付かない・経路で落ちやすい）

スコアが示すこと: 機密性・完全性・可用性すべて高（C:H/I:H/A:H）

実際に必要な条件: 再送 SYN を別 CPU が並行処理する狭いレースを当てる

スコアが示すこと: 最悪はコード実行に至りうる

実際に必要な条件: 多くの場合はカーネルのクラッシュ（DoS）。RCE までは高難度

出典: CVE-2026-98432 の CNA スコア（CVSS:3.1 9.8・S:U）と修正コミットの説明（2026-10-29 確認）。評価は本記事の整理

一方で、この use-after-free を実際に踏ませるには、次の条件が重なる必要があります。

観点 内容
IP options が必要 request socket に ireq_opt が載るのは、SYN に IP オプションが付いているときだけ。多くのネットワークでは IP options は付かず、途中のルータで落とされることも多い
レースを当てる 同じ request socket への再送 SYN が、別の CPU で並行して処理される狭い時間窓を突く必要がある
多くは crash use-after-free を踏んでもすぐコード実行になるわけではなく、現実にはカーネルのクラッシュ（DoS）に終わることが多い
RCE は高難度 解放済みメモリの再利用を狙い通りに操るには、さらに作り込みが要る

だからといって放置してよいわけではありません。条件が揃えば可用性への影響（サービス停止）は現実的で、CVSS が示すとおり最悪はコード実行に至りうると評価されています。要は「9.8 だから今すぐ全面停止」と煽るのでも「条件付きだから無視」でもなく、通常のカーネル更新のサイクルで確実に当てるのが妥当、という温度感です。別のネットワーク系カーネル脆弱性の読み解きはFraggap｜Linux カーネル UDPv6 の境界外アクセス CVE-2026-53362が、同じ use-after-free をユーザー空間のサーバで見た例はNGINX HTTP/3 の Use-after-Free｜CVE-2026-42530・1.31.2 で修正が参考になります。解放済みメモリを読む同じ型のバグでも、起こる場所と悪用条件で深刻度の実際がどう変わるかが見えてきます。

自分のカーネルは該当するか：版を確認する

まず稼働中のカーネルの版を確認します。

# 稼働中カーネルの版を確認する
uname -r
# ディストリの提供するカーネルパッケージの版（例: Debian/Ubuntu 系）
dpkg -l 'linux-image-*' 2>/dev/null | awk '/^ii/{print $2, $3}'
# RHEL 系
rpm -q kernel 2>/dev/null

影響するのは Linux 4.4 以降で、各安定版の修正が入る前までです。修正が入ったのは 5.10.272 / 5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 / 6.18.56 / 7.2.10、本流は 7.3 です。ただし、多くのディストリビューションは独自の版番号にこの修正をバックポートしているため、数字をそのまま比べると分かりにくいことがあります。確実なのは、使っているディストリのセキュリティ告知（Ubuntu/Debian/RHEL など）で CVE-2026-98432 の「fixed」版を見て、それに合わせることです。

修正は net/ipv4/af_inet.c と net/ipv4/tcp_ipv4.c に入っています。カーネルの更新は、ライブパッチの仕組みが無い限り、パッケージを当てても再起動するまで反映されません。更新後の再起動を忘れないでください。

WHAT TO DO対応の確認項目

修正版カーネルへ・自分の版を確かめる

  1. 1.稼働中カーネルの版を確認する

    uname -r。影響は 4.4 以降。修正は 5.10.272 / 5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 / 6.18.56 / 7.2.10・本流 7.3

  2. 2.ディストリの更新を当てて再起動

    修正は net/ipv4 の af_inet.c・tcp_ipv4.c。live patch が無ければ再起動まで反映されない

  3. 3.修正の本体は kfree_rcu 化

    inet_sock_destruct() と tcp_v4_reqsk_destructor() の解放を RCU 猶予後に。読み手は既に RCU を使っている

  4. 4.IPv4 のみ・IPv6 は別対応

    IPv6 は tcp_v6_syn_recv_sock() がオプションを複製するため最初の問題の対象外。移行経路の件は別パッチで対応

出典: CVE-2026-98432 公式記録・修正コミット（git.kernel.org stable・2026-10-29 確認）

影響範囲：IPv4 のみ、IPv6 は別対応

この問題はカーネルの TCP/IPv4 の処理にあり、最初の問題（子ソケット生成時のオプション引き継ぎ）については IPv6 は対象外です。tcp_v6_syn_recv_sock() はオプションを複製するため、解放の競合が起きないからです。一方、先に触れた request socket の移行に関わる同種の問題は、IPv6 の ipv6_opt にも存在します。これは CALIPSO（IPsec 系のラベル付け）でのみ設定されるもので、別のパッチで対応される、とコミットは述べています。

この記事の結論

  • ・CVE-2026-98432 は TCP SYN_RECV 経路の実在する use-after-free。原因は IP オプションをコピーせず所有権だけ移したこと、修正は解放を kfree_rcu（RCU 猶予後）に変えること。
  • ・CVSS 9.8 は接続経路の広さを反映した最悪値。実悪用には IP options 付き SYN と並行処理のレースが要り、多くは crash（DoS）止まり。煽らず無視せず、通常のカーネル更新で確実に当てる。
  • ・影響は 4.4 以降。uname -r で版を確認し、ディストリの告知の fixed 版へ更新して再起動する。
  • ・IPv4 のみ。IPv6 は最初の問題の対象外で、移行経路の件は別パッチで対応される。

参照ソース