本記事の概要

本記事は「CVE-2026-99999（Linuxカーネルの脆弱性）」に関して、2026年10月17日時点の公開情報を元に個人的にまとめた備忘録。

CVE-2026-99999 って何なのよ？
どれくらいヤバいことなのよ？
どうやって発見されたのよ？
ここから学んだ、生成AIとの付き合い方について個人的な所感

こんな感じの内容で書いてます。

CVE・修正版・各事業者の対応状況は日々変わるため、実際の対応判断の際は必ず一次情報（CVEレコード、各ディストリビューションのアドバイザリ）とご自身の環境を確認してください。

1. CVE-2026-99999（PwnEscape）とは

概要などについて触れていきます。

CVE と CVSS のおさらい

CVE（Common Vulnerabilities and Exposures）＝共通脆弱性識別子 は、世界中で見つかったソフトウェアのセキュリティホール（脆弱性）に付けられる識別番号です。CVE-西暦-連番 という形式で採番される、脆弱性の "背番号" のようなものです。

深刻度は 「CVSS」 で 0.0〜10.0 の数値として評価されます。

スコア	深刻度	ざっくりした意味
0.0	None	実質的な危険なし
0.1〜3.9	Low	悪用が難しい、または被害が小さい
4.0〜6.9	Medium	条件が揃うとヤバめ。対応検討し始めるレベル
7.0〜8.9	High	早急な対応が必要。リモート攻撃や漏洩のリスク
9.0〜10.0	Critical	致命的な超ヤバいやつ。ニュースになるレベル。事業に直結する

概要

CVE-2026-99999（通称 PwnEscape; プーンエスケープ） は、pwn.ai の研究者 Paulos Yibelo 氏が見つけた Linux カーネルのネットワークスタックの脆弱性 です。CVE レコード上の CVSS v3.1 は 9.3（Critical）、ベクターは AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H です（CVE.org）。

報告された3つの影響と、どこまで実証されたか

影響ごとに「どこで実証されたか」が違うため、分けて読むのが大事です（Vercel 公式ブログ、pwn.ai）。

影響	実証環境
ホストメモリ漏えい（試験ケースでは 1 回あたり 32 バイト）	Vercel の本番 Sandbox で実証
ホストのクラッシュ（DoS）。同じホスト上の全VMが停止	研究者が用意した Linux 6.12 / 7.x のホスト
ゲスト → ホストへのエスケープ（ホストで root 実行）	研究者が用意した KVM / Firecracker 環境（コールドブート 4 回で再現）

「32バイト」はあくまで研究者の試験ケースでの値で、固定の上限ではありません。また root 取得はベンダーの本番環境では実証されていません。

めっちゃ簡単に言うと、「VMからホストのメモリ読める」「VMからホストクラッシュできる（同ホストの他VMも停止できる）」「VM脱獄してホスト乗っ取れちゃう（管理者権限持てる）」という報告です。うーん、なかなかのパンチ力 👊

2. どうやって見つかったのか

きっかけは、Next.js などをメンテする Vercel 社が 2026年8月に始めた 「$1M hacker challenge for Vercel Sandbox」 です。総額 100 万ドル（約1.5億円）、1 報告あたり最大 5 万ドルの賞金で、「どんなAIモデルを使ってもいいからサンドボックス（Firecracker microVM）を突破してみて」 という公開チャレンジでした。

個人的には 「Anthropic の最新モデル（Mythos）がサンドボックス突破できちゃった事件」 に端を発して、色んなAIの発表やニュースから開催されたと思ってます。

結果は次のとおりです（Vercel 公式ブログ）。

2 週間で 1,285 件の報告
支払われた報奨金は 242,000 ドル
Critical 1 件、High 5 件、Medium 9 件、Low 42 件
Linux カーネルのゼロデイ 1 件（これが PwnEscape）
顧客データへのアクセスを示す報告はなし

Paulos 氏は特別な権限のない標準の Sandbox からこの欠陥を見つけたとされています（Vercel）。報道によると、AI エージェントを使ってチャレンジ開始から 3 日で発見し、API 費用は 700 ドル未満だったそうです（The CyberSec Guru）。

開示から修正までのタイムライン

日付	出来事
2026/8/18	Vercel がチャレンジを公表
2026/8/20	研究者がホストメモリ漏えいの初期報告を提出
2026/9/4	カーネルのセキュリティ窓口・netdev メンテナへ根本原因と修正案を非公開で報告
2026/9/7	Red Hat の Michael S. Tsirkin 氏が再現を確認
2026/10/8	修正が `net.git` に取り込まれる（コミッターは Jakub Kicinski 氏）
2026/10/9	`net-7.3-rc7` のマージ（af32da41）で mainline 入り
2026/10/14	Vercel がチャレンジ結果を公表
2026/10/15	CVE 公開（12:19 UTC）、stable 版リリース、AWS がセキュリティ速報を公開

（タイムラインの出典：pwn.ai、修正コミット、CVE.org）

mainline へのマージ日について、pwn.ai の記事では「10月14日」となっていますが、GitHub 上の torvalds/linux では net-7.3-rc7 のマージコミット（修正を含む）が 10月9日付けになっていたのでそちらを採用。

3. 原因：チェックサム処理における「信頼の逆転」

ここが技術的な本題です。

前提：CHECKSUM_PARTIAL とは

Linux カーネルでは、パケットは struct sk_buff（以下 skb）という構造体で扱われます。TCP/UDP のチェックサム計算はコストがかかるため、「あとで（NIC かソフトウェアが）計算する」という**遅延計算（チェックサムオフロード）**の仕組みがあります。

この状態を表すのが skb->ip_summed == CHECKSUM_PARTIAL で、関連するフィールドは次の 2 つです（pwn.ai）。

フィールド	意味
`skb->csum_start`	チェックサム計算を始める位置
`skb->csum_offset`	`csum_start` から見た、計算結果を書き込む位置までのオフセット

つまり、最終的にチェックサムは csum_start + csum_offset の位置に書き込まれます。後段で skb_checksum_help() が呼ばれると、ソフトウェアで計算してその位置に書き込みます。

ポイントは、これらの値が「パケットの説明」ではなく、「あとでこの場所に書き込んでよい」という許可そのものだということです。研究者は次のように書いています。

“The critical point is that these values are not just descriptive metadata. They authorize a subsequent write into packet memory.”
（重要なのは、これらの値が単なる説明用のメタデータではないという点だ。パケットメモリへの後続の書き込みを許可するものなのだ。）
— pwn.ai

ゲストがメタデータを指定できる

VM の場合、ゲストは virtio-net ヘッダ（virtio_net_hdr） の中で csum_start / csum_offset を指定してフレームを送ります。VMM（QEMU や Firecracker）はそれをホストの TAP デバイスに書き込み、ホストカーネルの tun_get_user() → __virtio_net_hdr_to_skb() で skb のフィールドに変換されます（CVE レコードのCVSS根拠）。

入口のチェックが「座標系のズレ」で不十分だった

入口の __virtio_net_hdr_to_skb() にも最低限のチェックはありました。しかしそれは skb_transport_offset(skb)、つまりその時点の skb->data から見た相対位置で判定していました。L2 ヘッダ（Ethernet など）を剥がした後の**「ネットワークヘッダ（IPv4 ヘッダ）から見た相対位置」**を保証するものではなかったのです（pwn.ai）。

研究者は概念的に次の 2 つの不等式を示し、「この 2 つは同じではない」と指摘しています。

// 入口で確認していた条件（skb->data 基準）
transport_offset >= minimum_network_header_length

// 本来必要だった条件（ネットワークヘッダ基準）
transport_offset - network_offset >= minimum_network_header_length

その結果、「入口のチェックは通るのに、実は csum_start が IPv4 ヘッダの内側を指している」パケットを作れてしまいました。

「検証 → 書き換え → 利用」の順序が問題（TOCTOU）

修正前の ip_do_fragment() は、おおむね次の順序で処理していました（pwn.ai）。

/* 修正前（概念） */
if (skb->ip_summed == CHECKSUM_PARTIAL)
    skb_checksum_help(skb);   /* ← ここで遅延書き込みが走る */
iph = ip_hdr(skb);
/* この後、iph->ihl からヘッダ長 hlen を求めてフラグメント化する */

IPv4 ヘッダはすでにパース・検証・ルーティング済みです。ところが、そのあとの skb_checksum_help() がゲストに指定された位置（＝IPv4 ヘッダの中）にチェックサム値を書き込むため、検証済みのヘッダが書き換わってしまいます。

研究者の試験ケースでは、IPv4 ヘッダの先頭 1 バイトが次のように変わりました。

状態	先頭バイト	IHL	解釈されるヘッダ長
パース時（検証済み）	`0x45`	5 ワード	20 バイト
遅延書き込み後	`0x4f`	15 ワード	60 バイト

上位 4 ビット（バージョン = 4）はそのままで、下位 4 ビットの IHL（ヘッダ長）が 5 → 15 に変わるのがミソです。

このケースでは、skb の論理的な線形データは 28 バイト（IPv4 ヘッダ 20 バイト + 最初のフラグメントのペイロード 8 バイト）しかありません。ところがフラグメント処理は「ヘッダは 60 バイト」と信じてコピーするため、差分の 32 バイト分のホストメモリが「IP オプション」として外に送信されてしまいます。これが「32 バイトのメモリ漏えい」の正体です（pwn.ai）。

これは「skb の論理的な範囲」を越えた読み出し（out-of-bounds read）で、スラブオブジェクトの物理的な境界を越えるとは限らない、と説明されてます。

「信頼の逆転（trust inversion）」とは

まとめると、次のような信頼関係の破綻です。

入口（virtio / TUN）では、メタデータが最低限のチェックを通過する
IPv4 層では、ヘッダが検証済みとして扱われ、ルーティングなどの判断に使われる
その後の遅延書き込みで、信頼度の低いゲスト由来のメタデータが、信頼済みの IPv4 ヘッダを書き換える
フラグメント処理は、書き換え後のヘッダを再検証せずに利用する

“The problem was not how difficult IPv4 is to parse. It was that different parts of Linux were allowed to trust different versions of the same packet.”
（問題は IPv4 のパースが難しいことではなかった。Linux の別々の箇所が、同じパケットの「別のバージョン」をそれぞれ信頼してしまっていたことだ。）
— pwn.ai

いわゆる TOCTOU（Time-of-Check to Time-of-Use）ですが、スレッド間の競合（レースコンディション）ではなく、正規の処理順序の中に攻撃者が仕込んだ遅延書き込みが挟まる、決定論的な TOCTOU である点が特徴です。研究者はこのパターンを「deferred-metadata trust inversion」と呼んでいます。ただし、これは研究者自身による命名で、確立した分類名ではない点には注意してください。

簡単に言うと、「一度検証したパケットのヘッダを、ゲストが後からこっそり改ざんできる」 という構造でした。

4. 修正内容

修正は 6785011f8b16「ipv4: validate checksum_start before completing checksum」です。作者は Red Hat の Michael S. Tsirkin 氏、レビューは Willem de Bruijn 氏、コミッターは Jakub Kicinski 氏です（修正コミット）。

include/net/ip.h に共通のガード関数が追加されました。

static inline int ip_check_csum_start(const struct sk_buff *skb)
{
	if (unlikely(skb->csum_start < skb->network_header + ip_hdrlen(skb)))
		return -EINVAL;
	return 0;
}

そして ip_do_fragment() は**「検査してから書き込む」**順序に変わりました。

 	/* for offloaded checksums cleanup checksum before fragmentation */
-	if (skb->ip_summed == CHECKSUM_PARTIAL &&
-	    (err = skb_checksum_help(skb)))
-		goto fail;
+	if (skb->ip_summed == CHECKSUM_PARTIAL) {
+		err = ip_check_csum_start(skb);
+		if (!err)
+			err = skb_checksum_help(skb);
+		if (err)
+			goto fail;
+	}

保証される条件（不変条件）は次のとおりです。

csum_start ≥ IPv4 ヘッダの開始位置 + IPv4 ヘッダ長

つまり「チェックサムの計算開始位置が IPv4 ヘッダより後ろ にあること」を強制し、チェックサムの書き込み先が IPv4 ヘッダの中に入らないようにしています。

「csum_start がネットワークヘッダの範囲内にあることを強制する」と説明されることがありますが、実際は逆で、**IPv4 ヘッダの範囲より後ろ（外側）**にあることを強制するチェックです。また、このチェックは書き込み先が「正しい TCP/UDP チェックサム欄」であることまでは保証しません（pwn.ai）。

ガードは ip_do_fragment() を含む 5 箇所に入りました（変更は 6 ファイル、44 行追加・12 行削除）（修正コミット）。

ファイル	対象の処理
`include/net/ip.h`	共通ガード `ip_check_csum_start()` の追加
`net/ipv4/ip_output.c`	`ip_do_fragment()`（IPv4 フラグメント）
`net/bridge/netfilter/nf_conntrack_bridge.c`	ブリッジ conntrack のフラグメント処理
`net/netfilter/nfnetlink_queue.c`	NFQUEUE
`net/netfilter/xt_CHECKSUM.c`	iptables の CHECKSUM ターゲット
`net/xfrm/xfrm_output.c`	xfrm（IPsec）出力

ブリッジ conntrack の経路も含まれているので、「L2 ブリッジ構成だから安全」とは言い切れません。

なお、コミットメッセージ自身が「本来はこういうパケットを入口で通すべきではないが、多層防御（defence in depth）としてまず書き込み直前でチェックする。入口側のより完全な検証は作業中」と述べています（修正コミット）。つまり今回の修正は出口側の防御で、入口側（virtio_net_hdr の検証）の強化は今後の課題です。

修正済みのバージョン

CVE レコードでは、以下の stable 版以降が修正済みとされています（CVE.org）。

5.10.272 / 5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 / 6.18.57 / 7.2.11 / 7.3-rc7

ディストリビューションのカーネルは upstream より小さいバージョン番号に修正を backport している場合があるため、バージョン番号ではなく各ディストリのアドバイザリで判断してください。例えば Amazon Linux では、AL2 / AL2023 の各カーネル向けに修正版が出ています（Amazon Linux Security Center）。

5. コンテナでは起きるのか？

ここが個人的に一番気になったところです。結論から言うと、次のようになります。

「ゲストVM → ホスト」というエスケープの形は、VM 特有の問題
ただし欠陥はホストの Linux カーネルにあるので、コンテナが無関係とは言えない。「ローカル攻撃者」の経路として扱われている

VM の場合（典型的な攻撃パターン）

ゲスト VM は独自のカーネルを持ち、virtio-net などの仮想 NIC を通じてホストにフレームを送る
そのとき、ゲストは virtio_net_hdr の中でチェックサムのメタデータを自由に指定できる
VMM はそれを TAP 経由でそのままホストカーネルに渡すため、ホスト側のデバイスへのアクセス権もユーザー名前空間も不要

CVE レコードの CVSS 根拠も、まさにこの「microVM → VMM → ホストの TAP → tun_get_user() → ip_do_fragment()」という経路を想定しています（CVE レコード）。

コンテナの場合

コンテナはホストと同じカーネルを直接共有しています（名前空間と cgroups で隔離しているだけ）
ネットワークは通常 veth ペア + ブリッジ / NAT で処理され、普通にソケットで通信している限り、VM のような「ゲストからホストへチェックサムメタデータを渡す」経路はない
そのため、今回の「ゲスト→ホストのエスケープ」という攻撃パターンが、そのままコンテナに当てはまるわけではない

それでも「無関係」とは言えない理由

問題のメタデータは virtio だけでなく、次の入口からも注入できます（修正コミットの Fixes タグ、CloudLinux）。

入口	必要な権限
TUN/TAP デバイス（`IFF_VNET_HDR`）	`CAP_NET_ADMIN`（ユーザー名前空間の中でも得られる）
AF_PACKET ソケット（`PACKET_VNET_HDR`）	`CAP_NET_RAW`（ユーザー名前空間の中でも得られる）

研究者も「上流の議論では VM を使わない TUN / AF_PACKET のシナリオも検討された」と書いています（pwn.ai）。また Red Hat は、この脆弱性を「ローカルの攻撃者、または信頼できないゲスト VM が悪用できる」と説明しています（Red Hat Customer Portal）。

コンテナの視点で注意したいのは次の点です。

カーネルを共有しているため、影響は「ホストそのもの」に及ぶ
VM ならゲストのカーネルとホストのカーネルは別物ですが、コンテナの中から問題の処理に到達できた場合、壊れるのは最初からホストのカーネルです。「VM エスケープ」ではなく「ローカル権限昇格 / コンテナエスケープ」として現れる可能性があります。
Docker はデフォルトで NET_RAW を付与している
Docker のデフォルトケーパビリティには NET_RAW（RAW / PACKET ソケットの利用）が含まれています（Docker Docs）。一方、Podman などの containers.conf のデフォルトでは NET_RAW は付与されません（containers.conf）。
非特権ユーザー名前空間（rootless コンテナなど）
非特権ユーザーでもユーザー名前空間 + ネットワーク名前空間を作れる環境では、その中で CAP_NET_ADMIN / CAP_NET_RAW を持てます。CloudLinux は「VM のない共有ホストでも、非特権ユーザーがユーザー名前空間を作れる場合は影響を受ける」と整理しています（CloudLinux）。

ただし、標準的なコンテナ設定で攻撃が最後まで成立することは、現時点では公開情報で確認されていません。CloudLinux も、ユーザー名前空間内の TUN 経由の経路について「コード上はあり得るが、自社テストでは未確認」としています（CloudLinux）。実際に成立するかどうかは、修正対象の 5 つの処理（フラグメント、NFQUEUE、CHECKSUM ターゲットなど）に到達する経路があるかにも左右されます。

gVisor / Kata Containers は？

Kata Containers は中身が VM（QEMU / Firecracker など）なので、VM と同じ観点での評価が必要です
gVisor はユーザー空間に独自のネットワークスタックを持っていますが、ホストとの接続方式によって境界が変わります

「コンテナだから対象外」「VM 型だから全部対象」といった単純な判断はどちらも危険です。

参考：k2_naka 氏の Qiita 記事💁‍♂️

コンテナ環境での対策

何よりもまずホストカーネルを更新して再起動する（根本対策はこれだけかも…）
不要なら NET_RAW を落とす：docker run --cap-drop NET_RAW ...（Kubernetes なら securityContext.capabilities.drop）
NET_ADMIN や --privileged を安易に付けない
非特権ユーザー名前空間が不要なマルチユーザー環境では、無効化も選択肢になります（sysctl user.max_user_namespaces=0）。ただし rootless コンテナやブラウザのサンドボックスなどが動かなくなるので、影響を確認してから実施（CloudLinux）

AWS は「回避策はなく、修正済みカーネルの適用と再起動が必要」と案内している。上の 2〜4 はあくまで露出を減らす補助策で、カーネル更新の代わりにはならない。

6. 影響を受ける事業・サービス

攻撃の条件は「ゲスト VM の中で細工したフレームを送れること」です。CVSS の PR:N（権限不要）はホスト側の権限が要らないという意味で、ゲストの中では通常 root 相当の権限が必要です。
AWS も「ゲスト VM 内で特権を持つ攻撃者」と表現しており、Amazon Linux は独自に PR:L で 8.8（Important）と評価しています（Amazon Linux Security Center）。

とはいえ、クラウドやサンドボックスではゲストの root を利用者に渡すのが普通なので、実質的には「VM を借りられる人なら誰でも」攻撃の入口に立てることになります。そのため、Linux をホストにして信頼できないゲスト VM を動かしている共有インフラ（VPS、IaaS、AI エージェントのサンドボックスなど）は特に深刻です。

主な事業者の反応は次のとおりです。

AWS：EC2・Lambda・Fargate などのマネージドサービスは影響なし。影響を受けるのは、ベアメタルやネスト仮想化の上で KVM / Firecracker を自分で運用しているホスト

さくらインターネット：影響の有無と範囲を確認中で、さくらのクラウドの新規プロジェクト作成を一時停止（k2_naka 氏の Qiita 記事も参照）

AWS の速報は影響範囲を「4.4〜6.18 の未修正カーネル」と表記していますが、CVE レコードでは 2.6.27 以降が対象で、7.2 系も含まれます。バージョン範囲は CVE レコードで確認するのが確実です（AI Heartland）。

自分の環境を確認するには

※ あくまで参考程度に。

# 実際に動いているカーネルを確認（インストール済みではなく「実行中」）
uname -r

# Docker コンテナに付与されているケーパビリティを確認
docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}' <container>

# 非特権ユーザー名前空間が作れるかを確認（失敗すればその経路はない）
unshare -Urn true && echo "userns: 作成可能"

カーネルパッケージを更新しても、再起動するまでは古いカーネルが動いたままです。「インストール済み」と「実行中」を区別して確認しましょう。

7. 今回の企画の意義と、AIとの付き合い方

脆弱性を発見するイベントを企画した Vercel 社長ギルレモさん（Guillermo Rauch 氏）も 「これはめっちゃ貢献度が高い "エキサイティング" なイベントだったわ！」 とご満悦でした。

かなり深刻な内容なので、手放しで喜ぶテンションには個人的に少し違和感もあります。
ただ、今回の件は「才能ある技術者・研究者が、AI エージェントのスウォーム・専門知識・忍耐力を武器にすれば、世界に影響する重大な発見ができる」ことを示す一つの事例になったと感じます。

将来的に、時間の問題で生成 AI が一定のラインを超えたら起きたかもしれない大事故を、「AI を武器にしつつ、人間も積極的に思考実験に参加する」という仕組みによって、事前に検知して対応できる可能性 を示した、ということです。
実際、2008 年から 18 年近く誰にも気づかれなかったバグが、AI を使った研究者によって 3 日で見つかりました。

今回の教訓の１つは、Vercel 自身が挙げているように、サンドボックス（VM）の外から返ってくる値はすべて「信頼できない入力」として扱うことです（Vercel 公式ブログ）。今回のバグもまさに、ゲストから渡されたメタデータを信頼してしまったことが原因でした。AI エージェントにコードを実行させる基盤が増えている今、この原則はますます重要になっていくはずです。

そしてもう１つの教訓は、最近「AI 様にすべて任せて、足手まといな人間どもは身を引きなさい」という流れも一部SNSでありますが、今回はむしろ 人間と生成 AI のコラボレーションの重要性 を再確認できる事例だと思います。

今後は、全てをAIだけで回すだけの事業やサービスよりも、今回のようなAIをフル活用して人間も積極的に参加する構造を持った（＝それが上手くハマる方法を発見した）事業やサービス・会社・個人が、どんどん開拓をして格差を広げていくのかも知れないと個人的には感じました。

今回は技術者向けに書いたので、よりざっくり抽象化した簡略版は、以下のX記事をご覧ください。

参考資料