xen0bit/netprobe-cve-2026-98432CVE-2026-98432（Linux IPv4 TCP の ireq_opt ユースアフターフリー）を、差分 SYN-ACK オプションエコーによるブラックボックスリモートプローブと、静的 vmlinux 検証によって検出します。
こんにちは。CVE-2026-98432 は Linux カーネルにおけるリモートから悪用可能な Use-After-Free です。一部の報道では、AI ラボが Multi-Path TCP（MPTCP）経由で約45分でこれを悪用したとされています。この脆弱性は実際には IPv4 TCP スタック自体に存在するものであり、MPTCP は脆弱なコードパスに到達するための、唯一と言ってよいほど現実的な手段にすぎません。それでもなお、約45分という数字には非常に深く疑いの目を向けるべきです。
ireq_opt のロードから最初のデリファレンスまでの距離にほぼ固定されています。MPTCP をパケット単位のステアリングオプションとともに使用するカスタム Linux カーネルは確かに存在し、それらはこの脆弱性を「純粋な意味で到達可能」にしている可能性が高いです。実用上、あなたがそのようなカーネル構成を実行している可能性はほぼ確実に低く、また誰かがレイテンシ的に十分近く、かつ十分に執拗にその隙間を狙い撃ちできるほど運が悪いということもほぼありません。
悪用を多少なりとも現実的にする主な要因は、仮想化/オーバーサブスクライブされた VM であり、PREEMPT_RT、threadirqs などが用いられている場合です。これは攻撃者が追加の特権/認証済みアクセスを持たない限り、制御も影響も及ぼせないものです。業界には私の考えを変えるようなトリックをいくつか知っている友人がいるかもしれませんが、私自身は何も知りませんし、AI も何も出せませんでした。少なくとも、その「トリック」が存在するとしても広く知られているものではありません。
サーバーにはパッチを適用すべきですが、おそらくパニックになる必要はありません。このリポジトリ内の他のすべて（以下の行を含む）は AI によって生成されたものですが、私はセッションを誘導し、成果物の正確性をレビューしました。
以下は：
カーネルバージョンの照合ではなく、パケットレベルの証拠によって CVE-2026-98432（Linux IPv4 TCP の ireq_opt / inet_opt use-after-free）の存在を実証するリモートブラックボックスプローブです。
これは use-after-free の時点で停止します。つまり、カーネルが解放済みメモリを読み取り、そのことをネットワーク上で示したことを証明します。KASLR のバイパス、制御フローの乗っ取り、コードの実行は行いません。
許可されたテストのみに使用してください。レースプローブはターゲットを不安定にする可能性があり、カーネルクラッシュは十分にあり得る結果です。所有しているホスト、または書面による許可を得てテストするホストでのみ使用してください。
修正は e3f33b0a1d89d738e2b913dab519226eaf76e15b（ipv4: free inet_opt and ireq_opt after an RCU grace period）であり、inet_sock_destruct() と tcp_v4_reqsk_destructor() において kfree() を kfree_rcu() に変更する2行の変更です。
tcp_v4_init_req() は、SYN でエコーバックされた IP オプション（Record Route / Timestamp）を ireq->ireq_opt に格納します。tcp_v4_syn_recv_sock() は、ポインタをコピーするのではなく、子ソケットにポインタを転送します。rcu_read_lock() の下で ireq->ireq_opt を読み取り、ip_options_build() で使用します。この最後の点が検出器です。カーネルは古いオプションバイトを送信者にエコーバックします。
スコープの訂正：CVE レコードは一般的な IPv4 TCP です。「multipath TCP リスナー」に結びつけているのは Anthropic のブログのみであり、CVE/NVD/Red Hat/Debian/Ubuntu のいずれの文書も MPTCP に言及していません。プローブはまずプレーンな TCP をテストします。
弱いものから強いものへ、3つの独立したレッグ：
| レグ | 示す内容 | 成果物 |
|---|---|---|
| 静的（build-id 固定） | 実行中カーネルのコード形状: 両方のデストラクタで素の kfree = 脆弱; kvfree_call_rcu = 修正済み | verify-local、下の表 |
| 合成オラクル | レスポンダが再利用された slab メモリをエコーすると、ワイヤ検出器が発火する | scripts/validate_synthetic.sh → CONFIRMED VULNERABLE |
| 動的、カーネルレベル（KVM ラボ） | KASAN が ip_options_build 内の実際の slab-use-after-free を、コミットのスタックとともに報告する; 同一トラフィックの kfree_rcu カーネルはクリーン | evidence/guest-inst-vuln6-KASAN.log、evidence/guest-inst-patched2-CONTROL.log |
| ワイヤ可視、実カーネル（非 KASAN ラボ） | ワイヤ上の SYN-ACK が、エコーされたタイムスタンプの代わりにスプレーされたオプションブロック（42 04 be ef…）を運んだ; kfree_rcu コントロールはクリーンのまま | evidence/race-stage1-wire-uaf.json、evidence/race-control-kfree_rcu.json |
動的レグは専用に構築された 7.0.14 ゲスト（KASAN + ブートパラメータによる
ウィンドウ拡張）で、パケットごとの CPU ステアリングを備える: 再送された SYN は
1 つの vCPU で処理され、ACK/転送は 2 つ目で、被害者の
accept()+close() は 3 つ目で行われるため、上書きは偶発的ではなく日常的に発生する。
カーネル自体が報告した:
BUG: KASAN: slab-use-after-free in ip_options_build
Read of size 16 ... by task swapper/0 (cpu0, softirq)
__asan_memcpy <- ip_options_build <- ip_build_and_send_pkt
<- tcp_v4_send_synack <- tcp_rtx_synack <- tcp_check_req <- tcp_v4_rcv
Freed by task 1 (victim, cpu3):
kfree <- inet_sock_destruct <- __sk_destruct <- inet_release <- __x64_sys_close
object: kmalloc-96, 16 bytes in (struct ip_options at the rcu_head offset)
さらに30件のリーダー側 READ-AFTER-FREE レコード（free後71～322 µsで読み取り、optlen=40、KASAN shadow 0xfb）。パッチ適用済みの対照（kfree_rcu、オブジェクトファイルで検証済み）で同じレースと保持を実行した結果：KASAN 0件、read-after-free 0件。これが脆弱性であり、バージョンの推測ではない。
リーダーは長いループではない。tcp_v4_send_synack() は ireq->ireq_opt をロードし、それを ip_build_and_send_pkt()/ip_options_build() に渡す。その memcpy が use-after-free の読み取りであり、ロードと読み取りは数命令しか離れていない（数十～数百ナノ秒）。free側 — 被害者の accept()+close() 後の子プロセス破棄 — ははるかに後である：測定されたクローズサイクルだけで61～92 µsであり、ACK→破棄のレイテンシにクロスCPUのウェイクアップが加わる。
したがって、この2つのイベントは単に同時に起こりにくいだけでなく、構造上約90 µs離れているのであり、読み取りはfreeよりずっと前に終わっている。自然タイミングの実験がそれを定量化する：同じ計装カーネルで、ウィンドウの引き伸ばしなし、約14万回のレース試行と並行するハーフオープンのチャーンにより、
stats: frees=180223 overlaps=0 raf=0 KASAN: 0
解放されたバイト列がリーダーのウィンドウ内に着地することは一度もなかった。より強力な2回目の試行では、ラボのスラブスプレーを使用した。8,000回の試行がそれぞれ200個の再送信SYN（160万個の独立したリーダーウィンドウ）を運び、リーダーvCPUが実行可能状態に保たれ、ホストのCFSハッガーによってプリエンプトされるクリーンなカーネルに対して行われたが、それでもスプレーを運ぶSYN-ACKはゼロだった。リーダーvCPUは実行時間の約5 msごとに1回プリエンプトされる。約10 nsの2M個のウィンドウ対20〜40秒の実行時間では、完全に均一なモデルであっても数回のヒットがあるはずであり、観測されたゼロは、プリエンプション点がゲスト命令ストリーム内で均一ではないことを示している。
したがって、ワイヤ上での証明にはリーダーを決定論的に遅延させる必要があり、ラボではブートパラメータのウィンドウストレッチ（reader_hold_us）でこれを行っている。実際のターゲットでは、これらの約10 nsの間にハイパーバイザまたはスケジューラのストールが発生する場合にのみ可能である。これが、リモートプローブが陽性を証明として扱い、陰性をバウンドとして扱い、「パッチ済み」とは決して見なさない理由である。
もう一つの帰結として、KASANカーネルでは隔離機構が解放されたバイト列をそのまま保持するため、UAFが発生してもワイヤ上ではそれを示すことができない。プロダクションカーネルでは、ワイヤオラクルは、解放されたkmalloc-96スロットがリーダーのmemcpyより前に再利用された場合にのみ発火する。この経路はもはや合成的なものだけではない。非KASANのラボカーネル（隔離機構なし）では、被害者が子をクローズし、直ちにそのスロットを40バイトのオプションオブジェクトで再割り当てし、カーネルがそれらをSYN-ACKにコピーした（42 04 be ef…、evidence/race-stage1-wire-uaf.json）。kfree_rcuを使用した同じカーネルでは何も生成されなかった（evidence/race-control-kfree_rcu.json）。
uv run netprobe preconditions -t <target> -p <port>
NOT_REACHABLE。IPPROTO_MPTCP 接続も試行し、MPTCP_INFO を確認するため、
「MPTCP リスナー」という主張を直接検証できます。各タプルについて、プローブはベースラインの SYN-ACK オプション構造
S0 = (total option length, ordered (kind, length, pointer)) を記録します。
その後、重複 SYN、ACK、RST をマイクロ秒単位のオフセットで競合させます。重複 SYN により
tcp_check_req() が ireq_opt を読み取り、ACK がポインタを子に渡し、RST がそれを解放します。
その後に続く SYN-ACK の構造が S0 と異なるものは、正しいカーネルでは発生し得ません。
これは片側からの証明であり、KASLR リークやクラッシュに依存しません。
タイムスタンプ値と記録ルートアドレスは比較から除外されます。
Linux はエコー時に両方を書き換えるためです（検証済み: ポインタは len+1 に強制され、
両方のタイムスタンプスロットはカーネルクロックで置き換えられます）。
| 判定 | 意味 |
|---|---|
CONFIRMED_VULNERABLE | 構造的なエコー異常をパケット付きで捕捉 |
INCONCLUSIVE | N 回試行、異常なし。明示的に弱い否定 |
NOT_REACHABLE | IP オプションのエコーなし、または ireq_opt 割り当てパスなし |
このツールは決して「パッチ済み」を出力しません。リモートからの否定は証明にはなりません。
パッチ済みカーネルでは試行ごとの確率はゼロですが、脆弱なカーネルではそれは小さく未知であるため、
クリーンな実行はそれを境界付けるだけです（1-(1-p)^N）。
spoof（このサンドボックスで検証済み）ルーティング可能だがローカルではない送信元アドレス（例: 203.0.113.7）から SYN を送信します。
ターゲットの SYN-ACK はインターフェースから送出され、ローカルカーネルはそれを処理しないため、
自身の RST を送出できません。プローブは AF_PACKET で SYN-ACK を捕捉し、
ACK / 重複 SYN / RST のタイミングを完全に制御します。
スキャンホストから到達可能なターゲット（ラボ、オングリンク、または送信元を偽装して到達できる
ターゲット）に対して機能します。必要なのは CAP_NET_RAW のみです。
sudo uv run netprobe race -t 172.18.0.3 -p 9101 \
--iface eth0 --spoof 203.0.113.7 --variant child -n 100000
firewall（リモートターゲット、このサンドボックスでは実行されません）実際のリモートターゲットに対しては、SYN-ACK がスキャナ自身のアドレスに返ってきて、カーネルがそれに RST を返します。これらの RST を抑制するには CAP_NET_ADMIN が必要です:
sudo uv run netprobe race -t 198.51.100.10 -p 80 --mode firewall -n 100000
これは、プローブの SO_MARK を持たない限り、プローブポート範囲内でローカルに生成された RST をドロップするスコープ付き nftables ルールをインストールします（netprobe/netfilter.py）。開発に使用したサンドボックスには CAP_NET_ADMIN（CapEff 0xa80425fb）がないため、このパスは生成およびユニットテストされていますが、ここではエンドツーエンドで実行されていません。
検査可能なホストでは、フリーコールの形状は決定的です：
uv run netprobe verify-local \
--vmlinux /usr/lib/debug/boot/vmlinux-$(uname -r) \
--expected-build-id "$(readelf -n /sys/kernel/notes | awk '/Build ID/{print $3}')"
kfree → 脆弱; kvfree_call_rcu → 修正済み。両方のクラスで検証済み: