CVE-2026-99999（PwnEscape）を読み解く──「KVMの脆弱性」ではなく、Linuxネットワークスタックの脆弱性

工程	担当
課題提示・取捨選択・内容チェック	筆者
原案作成・編成	Claude Fable 5.1
事実検証（検証メモ）	GPT-6 Astra
一次資料照合・最終稿	Claude Fable 5.1

本稿は筆者個人の分析であり、所属組織や各事業者の公式見解ではありません。基準日は2026年10月16日（資料確認 21:24 JST）です。CVE・修正版・各事業者の対応状況は変動するため、適用判断時には原典と自環境を再確認してください。本文の参照番号 [n] は末尾「参照」の根拠URLに対応します。

本稿での「確認」の範囲
本稿は公開資料の照合に基づくリスク検討であり、筆者による攻撃の再現試験や、各事業者の非公開構成の監査ではありません。研究者の実験結果、事業者の公表、筆者の分析を区別して書きます。※は本稿で確認できなかった事項を示し、「未修正」「非該当」「その事実が存在しない」のいずれも意味しません。

結論

• 欠陥の所在はKVM本体ではなく、Linuxカーネルのネットワークスタックです。ゲストから渡された不正なチェックサムオフロードのメタデータが、ホスト側で検証済みのIPv4ヘッダを後から書き換えます。VMを使わないTUN／AF_PACKET経路も検討対象で、「Linuxゲスト自身には関係がない」という意味ではありません [3][15]。
• 公開報告には、ホストメモリ漏えい、ホストの可用性障害、ホスト側の管理者権限でのコード実行という実証範囲の異なる3種類の影響があります。Vercel本番Sandboxで実証されたのはホストメモリ漏えいで、クラッシュとコード実行は研究者所有環境での報告です。漏えいが確認されたことだけから、すべての環境でroot取得まで成立するとはいえません [13][15]。
• CVE-2026-99999は正式公開済みで、CNAのCVSS v3.1基本値は9.3／Critical。mainlineおよび主要stable系列に修正が収録されています。 AWSの管理サービスに関する影響なしの告知と、さくらの調査・予防的対応は、第5節で範囲を分けて整理します。運用上は「影響し得るLinuxがどの階層にあるか」「誰が管理するか」「修正済みのカーネルで実際に稼働しているか」を確認します [2][10][16]。

1. 事実関係の確認

CVEと修正

• CVE-2026-99999は正式採番・公開済み。 Linux CNAのレコードの公開日時は2026年10月15日12:19 UTC（21:19 JST）、状態は PUBLISHED、対象修正は 6785011f8b16。CNAによるCVSS v3.1基本値は9.3（Critical）、ベクターは AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。 CNAが説明するゲスト→ホスト経路では、AV:Lはゲスト／仮想デバイス経由を意味し、通常のインターネット受信パケットだけによる攻撃ではありません。PR:Nはこの経路でホスト側の資格情報・capability・/dev/net/tun への直接アクセスが不要であるという評価で、ゲストが不正なメタデータを送れるという入力条件は必要です。VMを介さないTUN／AF_PACKETシナリオの権限条件まで不要になるわけではありません [1][2][30]。
• 修正コミット：torvalds/linux 6785011f8b16「ipv4: validate checksum_start before completing checksum」（作者 Michael S. Tsirkin、署名はRed Hatのメールアドレス／コミッター Jakub Kicinski、Cc: stable）。コミットメッセージの要旨は、不正なチェックサムメタデータがIPv4スタックに入ると skb_checksum_help がネットワークヘッダを壊し得ること、Paulosが発見・報告して他者も独立再現したこと、入口側の包括的な検証を今後の課題としつつ、まず完成処理の直前に防御的チェックを入れること、です [3]。
• Fixesタグの対象：f43798c（tun: Allow GSO using virtio_net_hdr、2008年7月）と bfd5f4a（packet: Add GSO/csum offload support、2010年2月）。CNAは影響開始版を2.6.27としています。AWSの告知には「4.4〜6.18の未修正カーネル」という別の範囲表記がありますが、これをLinux全体の影響版・非影響版を網羅した一覧とは扱いません。該当コードが存在することと実際に攻撃が到達することは別で、修正の有無・不正メタデータの入力可否・該当処理への到達性で決まります [4][2][10]。
• 変更6ファイル・保護5箇所：①include/net/ip.h に共通ガード ip_check_csum_start() を追加、②net/ipv4/ip_output.c の ip_do_fragment、③net/bridge/netfilter/nf_conntrack_bridge.c の nf_br_ip_fragment、④net/netfilter/nfnetlink_queue.c の nf_queue_checksum_help、⑤net/netfilter/xt_CHECKSUM.c の checksum_tg（CHECKSUMターゲット）、⑥net/xfrm/xfrm_output.c の xfrm_output。44行追加・12行削除 [3]。

/* 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() の修正後の順序：検査してから完成する */
if (skb->ip_summed == CHECKSUM_PARTIAL) {
    err = ip_check_csum_start(skb);
    if (!err)
        err = skb_checksum_help(skb);
    if (err)
        goto fail;
}

Vercelの公表との整合

• Vercelは「Linuxカーネルのゼロデイ1件」を最重要の発見とし、Paulos Yibelo（pwn.ai）が特別なアクセス権を付与されていない標準Sandboxからネットワークスタックの欠陥を見つけたこと、クラッシュとコード実行は研究者自身のKVM/Firecracker環境で実証されたこと、主要クラウドの多くが同じ層で顧客ワークロードを分離しているため共有インフラのリスクであることを述べています。募集時の脅威モデルはコンテナ内root・microVM内カーネルアクセスまで想定しており、「ゲストOS内でも非特権だった」という意味ではありません [13][14]。
• 初期報道には「メモリ漏えいとホストクラッシュの2件の独立した欠陥」とする説明がありましたが、10月14日のVercel公式はひとつのネットワーク欠陥から漏えい・クラッシュ・コード実行を説明しています [32][13]。
• Vercelの数字：受付報告1,285件、有効報告57件、支払済み報奨総額242,000ドル、Critical 1件。研究者個人への報奨額は報道で50,000ドル（チャレンジの1報告当たり上限と同額）とされますが、実支払額を示す一次資料は未確認（※）[13][14][32]。

呼称の注意
「KVM escape」という呼称は、研究者の実証でゲスト／ホスト境界を越えたという意味であり、脆弱性の所在はKVMではありません（記事自身がFigure 1で明記、修正対象もIPv4・netfilter・xfrm）。初期報道にはKVM自体の欠陥かどうか不明とする混乱が残っているため、記事タイトルに引きずられないようにしてください [3][15]。

2. 技術的メカニズムの要点

1. CHECKSUM_PARTIAL はskbに「後で csum_start + csum_offset の位置へチェックサムを書く」約束を持たせます。ゲストはvirtio-net headerでこの値を指定できます。これはIPv4ヘッダチェックサムのオフロードそのものではなく、不適切な位置指定によってネットワークヘッダが書き換わる点が問題です [26][15]。
2. 研究者が指摘した入口（__virtio_net_hdr_to_skb）の従来の最小長検証は、skb->data 相対の条件だけでは、L2ヘッダ除去後の「ネットワークヘッダ相対」の位置関係を保証していませんでした（座標系のズレ）[15][3]。
3. ホスト側の出力フラグメント処理 ip_do_fragment() では、従来「チェックサム完成 → IPヘッダ取得・ihl読み出し」の順だったため、遅延書き込みがIPv4ヘッダ先頭（例：0x45→0x4f、IHL 5→15語）を書き換え、すでに20バイトとして検証・ルーティング済みのヘッダを60バイトとして再解釈させます [15][3]。
4. 研究者の試験ケースでは、論理的な線形データ28バイトに対して60バイトのヘッダコピーが起きるため、差分の32バイトがホストメモリとして「IPオプション」に乗って外に出ます（アロケータの物理境界ではなく、skbの論理境界に対するOOB read）。32バイトはこのケースの値であり、固定量・上限ではありません [15][3]。

パケットの見え方	先頭バイト	IHL	解釈されるIPv4ヘッダ長
解析時の状態	0x45	5語	20バイト
遅延書き込み後	0x4f	15語	60バイト

以下は研究者が説明したIPv4フラグメント経路の模式図で、すべての構成に共通する処理順を示すものではありません [15][3]。

要するに「同じパケットを、カーネルの別々の箇所が別々の状態として信頼した」というTOCTOU型の問題です。スレッド競合ではなく、検証と後続利用の間に遅延書き込みが入る決定論的な処理順の問題として説明されています。研究者はこのパターンを「deferred-metadata trust inversion」と呼ぶ一方、構成要素には既知の技術が含まれるとも述べています。この名称と新規性評価は研究者の主張であり、確立した分類名や、他のプロトコル・製品の脆弱性を示す証拠とは扱いません [15][2]。

3. リスク評価

攻撃者の立場・条件

• 必要なのは、不正なオフロードメタデータ付きフレームを受け入れる入口（virtio-net→TAP、またはTUN／PACKET_VNET_HDR 付きAF_PACKET）と、未修正Linux側で該当する完成処理に到達する経路の両方です。ゲストrootは典型条件ですが普遍的な十分条件ではなく、ハイパーバイザのバグは不要です [2][3]。
• 公開修正で保護された到達先は5箇所（ip_do_fragment、ブリッジconntrackのフラグメント、NFQUEUE、CHECKSUMターゲット、xfrm出力）。典型的にはホストがゲストトラフィックをルーティング／NATしてIPフラグメントする構成が検討対象になりますが、製品の「default NAT」といった名称だけで成否は決まりません。逆に、ブリッジconntrackを通る構成もあるため、「L2ブリッジだから安全」という名称による判定もできません。これらは公開修正の保護対象であり、関連するすべての変種を網羅した必要条件の一覧とはしません [3][15]。
• VMなしでも成立しえます。 研究者の初期パッチ説明は、VMゲストを必要とせずvirtio-net headerを扱うTUNデバイスで足りると明示しており、AF_PACKET側の検証修正も含まれています。コンテナ／user namespaceからの到達性は、TUN作成に関わる CAP_NET_ADMIN、AF_PACKETソケット作成に必要な CAP_NET_RAW（そのnetwork namespaceを管理するuser namespace内）、渡されたファイル記述子、後続経路の各条件で決まります。標準的なコンテナ設定での完全な攻撃成立は未確認（※）[15][7][27][28]。

影響の深刻度

報告された影響	実証状況	意味
ホストメモリ漏えい（試験ケースで32バイト／回）	研究者が対照実験つきで再現。Vercelは本番Sandboxでのホストメモリ漏えい実証を公式に認めている（同社によれば、顧客データへのアクセスを示す報告はなかった）[15][13]	マルチテナントで「機密性」の侵害。後続攻撃でのKASLR／ヒープ状態の推定に使える可能性があるが、任意位置の読み出しや他テナントのデータ取得が実証されたわけではない
ホストDoS	研究者所有のLinux 6.12および7.x系ホストで確認（記事原文の記述）。サブバージョン・設定の全範囲での再現性は未確認（※）[15][13]	当該Linuxがクラッシュ等で停止すると、そのカーネルに依存するVM群に停止・利用不能が及びうる。ネストした中間ホストや単一VM内のLinuxであれば、直ちに下位の物理ホストや他テナント全体の停止を意味しない
64バイトの選択的カーネル書き込み→ホストroot	研究者は、自身のKVM実験環境でホストroot権限のヘルパーを実行し、別々のコールドブート4回で再現したと報告。Vercelもクラッシュ・コード実行は研究者所有機での実証と区別している [15][13]	研究者の実験環境におけるゲスト→ホスト境界侵害の報告。任意アドレスへの汎用的な書き込み、任意構成での成功率、ベンダー本番環境でのroot取得まで確認されたとは扱わない

エクスプロイトの流通見込み

確認した研究記事のPart 1は完全なエクスプロイトコードを掲載しておらず、ホスト制御までの過程を扱うPart 2を予告しています。第三者を含む全公開場所でPoCや続編が存在しないことまでは確認していません（※）。研究者は、比較的弱い構成向けは数週間、デフォルト構成向けは1か月以内にエクスプロイトが現れると予測していますが、対象となるデフォルト構成の全範囲や、実際の完成・流通時期が確認されたわけではありません。筆者のリスク判断としては、この予測を期限や安全な猶予期間とみなさず、公開済みの修正と自組織の露出条件に基づき更新を優先します [15]。

誰が当事者か

• 評価対象：Linuxカーネルをホストとし、virtio-net／TAP等を通じてゲストのメタデータを受け入れる仮想化・サンドボックス基盤（KVM/QEMU、Firecracker、Proxmox、OpenStack、oVirt、Linux上で動くcrosvm等のVMM、AIエージェント用サンドボックス）。Linuxホストであることは該当性の十分条件ではありません。 修正状況、仮想NIC、メタデータ受け入れ、Linux skb経路、後続処理の確認が必要で、製品名だけで影響を確定しません。vhost-user／DPDK／SR-IOV等を使う場合も、技術名だけではなく、対象トラフィックが問題のLinux skb処理を通るか、途中でTAP等へ戻るかを調べます。VMを介さずTUN／AF_PACKET入力を扱うLinuxも別途評価対象とします [2][25][19]。
• 非Linuxの基盤と、その上のLinuxを区別する：VMware ESXiのVMkernelやWindows Hyper-V自体は、今回のLinuxコードの直接の修正対象ではありません。Azureの基盤もMicrosoftはWindows Hyper-Vベースと説明しています。Linux VMを動かしているだけで、その収容先のESXiやHyper-Vの物理ホストが本件で脆弱になるわけではありません。 ただし、ゲスト内LinuxでTUN／AF_PACKET等から該当処理へ到達できる場合や、そのLinuxがさらにKVM等のホストになっている場合は、そのLinux自身の影響を別途評価します。どのLinuxが侵害されるのかと、どの境界を越えるのかを分けて判断します [3][2][22][27][28]。
• gVisor／Kata Containers：gVisorは独自のユーザー空間網スタックを持ちますがホスト接続方式で境界が異なり、KataはVMを使うため選択したVMM・ホストカーネル・バックエンドの評価が必要です。「コンテナだから対象外」「VM型だから全て対象」のいずれも不適切です（構成別影響判定は未確認※）[23][24]。
• IPv6：採用済み修正とIHL書き換えによる漏えいの実証はIPv4が対象です。原記事は、入口検証の議論にはIPv6や入れ子のヘッダ等も関係すると説明していますが、本稿ではIPv6で同等の漏えい・root取得が実証されたことは確認していません（※）。これは「IPv6には関連する問題がない」という確認ではなく、IPv6への切替だけで安全になるとの結論も導けません [3][15]。

自組織のLinuxが評価対象かを判定する流れを図にすると次のようになります。

4. 修正・配布の現状（10月16日時点）

対象	状況
mainline	10月8日にJakub Kicinskiがnet.gitへ適用（patchwork bot通知）。同日のLinus宛てpull要求（Networking for v7.3-rc7）が10月9日にマージ（マージコミット af32da41、タグ net-7.3-rc7）。pwn.ai記事の「10月14日マージ」は公開履歴と整合しない [5][6][15]
stable	CNAレコードに示された各stable系列の修正版は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11。10月15日のリリースについては6.1.190・7.2.11の変更履歴でも対象修正を確認。7.0／7.1への個別backportは本稿では未確認（※）で、「7.x全体が修正済み」という意味ではない [2][9]
Amazon Linux	AWS Security Bulletin 2026-137-AWSは10月15日10:30 PDT（16日02:30 JST）公開。AL2：kernel-4.14.355-287.750.amzn2、kernel-5.4.302-229.494.amzn2、kernel-5.10.269-270.1108.amzn2、kernel-5.15.220-156.256.amzn2。AL2023：kernel-6.1.188-233.385.amzn2023、kernel6.12-6.12.110-135.201.amzn2023、kernel6.18-6.18.51-120.162.amzn2023。告知はこれら以降を修正済みとしている。upstreamより小さいベース版数でも、修正がbackportされている場合がある。 自己管理する対象ホストについて、更新パッケージの適用と再起動を案内しており、回避策は示していない [10]
Debian／Ubuntu	Debianの公式トラッカーでは、ソースパッケージ linux のsid 7.2.11-1 が fixed、bookworm・trixie・forkyの掲載版には vulnerable 表示がある。Ubuntuの公式ページには Needs evaluation の系列がある。評価待ちを「脆弱と確定」「修正済み」のいずれにも読み替えない。 自分のリリース・カーネル系列・実行中ビルドを個別に照合する [11][12]
RHEL／Rocky／SUSE／Proxmox	修正版の網羅確認なし（※）。各社アドバイザリで確認のこと
ライブパッチ	kpatch／livepatch／Ksplice等について、本CVEに対応した修正の提供・適用可能なビルド・適用状態は本稿では未確認（※）。仕組みが利用可能であることと、このCVEの修正が有効になっていることは別。AWSの確認できた指示は、対象の自己管理ホストの更新と再起動 [10]
入口側（virtio_net_hdr検証）の後続修正	採用済みコミットは、より包括的な入力検証には追加の作業が必要と説明している。公開メーリングリスト上では、10月7日のWillem de Bruijn案に10月8日に再提出要求（Changes Requested）があり、10月15日にTsirkinによるv2系列（7本）がnet-nextに投稿されている。ただし、これは10月16日時点で確認した投稿・レビュー段階の状態であり、各案の最新の受理・収録リリースの状態は未確認（※）。既知のIPv4ヘッダ書き換えに対する修正と、入力API全体の検証強化は区別し、後続案を待つことを既存修正の適用延期の理由にしない [3][15][8]

5. クラウド事業者の対応状況

• AWS：「EC2インスタンス、Lambda、FargateなどAWS管理のコンピュート・コンテナサービスは影響なし、利用者の対応不要」と明記。影響対象は「virtio-netとKVMで自己管理するVM（Firecracker等のVMM利用を含む）を未修正ホストで動かしている利用者」。Nitroは「KVMを基に独自開発・最小化したハイパーバイザ」というAWS自身の説明があり「KVMベース」は妥当ですが、一般的なLinux＋QEMU＋TAP／vhost-net構成と同じデータ経路だと推定するのは不適切です。Vercel Sandboxはbare-metal EC2上に自前のFirecracker基盤を構築しているため、Vercelのホストで実証されたこととAWS管理サービスが影響なしという告知は矛盾しません [10][18][14]。
• さくらインターネット：10月16日付の全社告知は、同日17:00時点でサービスへの影響有無・範囲を確認中としています。さくらのクラウドでは同日からプロジェクトの新規作成を一時停止し、再開時期は決まり次第案内するとしています。作成済みプロジェクトは引き続き利用でき、新規プロジェクト作成の一時停止による既存リソースの稼働への影響はないという説明です。これは脆弱性そのものや今後のメンテナンスの影響を否定した発表ではありません。専用サーバPHY／高火力PHYも新規プロジェクトが必要な申し込みはできず、今後ホストメンテナンスを含む対応を実施する可能性があるとしています。利用者自身がOSを管理するサービスは、OS・カーネル・構成に応じて提供元の更新情報を確認するよう全社告知で案内しています。この発表を、全ホストの脆弱性や侵害の確定と扱わないでください [16][17]。
• Google Cloud／OCI：Compute EngineがKVMベースのハイパーバイザを使うこと、OCIがKVMによるOracle Virtualizationを基盤とすることは各社公式文書で確認できますが、本CVEのサービス別影響判定・修正状況は未確認（※）。KVM採用という共通点だけで当事者と断定しません [20][21]。
• Azure：Microsoftは基盤ハイパーバイザをWindows Hyper-Vベースと説明しており、本件のLinuxコードを根拠に、その物理ホストの脱出を主張することはできません。ただし、利用者が運用するLinux VM自身や、その中の自己管理仮想化・サンドボックスは別途評価します。これは基盤の公表に基づく技術的整理であり、Azureの全サービスについて本CVEの個別影響判定を取得したという意味ではありません [22][3]。
• 告知が見つからないことは、未対応・対応済みのどちらの証拠にもなりません。

6. 公共部門・自治体の観点

この節は、前節までの公開資料を公共部門の運用へ当てはめた筆者の分析です。原典が自治体やガバメントクラウドの個別構成で攻撃成立を確認したという意味ではありません。

• ガバメントクラウド利用者：CSP管理の物理ホストを利用者が更新することはできません。ただし「打てる手がない」わけではなく、対象サービス・経路の確認、CSPへの照会（AWSは管理サービスへの影響なしを公表済み、さくらは調査中、Google Cloud／OCIは※）、委託先が構築した自己管理Linuxホスト（bare-metal上のKVM等）の更新確認、不審ワークロードの停止などは管理範囲に応じて可能です。誰がそのLinuxを管理しているかを先に特定します [10][17]。
• 「クラウドだから物理分離相当」への含意：本件は、特定の共有Linuxホスト構成でゲスト→ホストの隔離境界が破られた報告として説明資料に使えます。ただし、別テナントの顧客データの取得まで実証されたという意味ではなく、全クラウドの分離機構が同じ欠陥で破られる、ガバメントクラウドで同じ実証がされた、という事実にもなりません。分離方式の一般論と、本件による個別サービスの影響確認を分けて書きます [13][15]。
• 自治体・ベンダーのオンプレKVM基盤：仮に三層分離の各層をProxmox／libvirt等で仮想化していたり、Linux KVMベースのアプライアンスを利用していたりする場合は、その名称だけで脆弱性を確定せず、Linuxの修正状況と入力・到達経路を確認します。影響する構成には、ディストリ／ベンダーの修正済みビルドを適用します。信頼レベルの異なるVM（インターネット接続系とLGWAN系、外部委託先VMと庁内VM等）が影響する同一Linuxホストを共有している場合は、境界横断リスクを優先して検討します。原典は自治体の三層分離構成を調査・実証していないため、これは筆者の当てはめです [3][2]。
• AIエージェント実行基盤：外向き通信を遮断していても、その前段のTAP／ホスト処理へ攻撃入力が到達するならリスクは残ります。一方、仮想NICがなく代替のTUN／AF_PACKET入力もない構成まで、この実証経路で危険とはいえません。「ネットワーク遮断」がどの層で実装されているかを明示して評価します。別のネットワーク分離回避事例を、本件の成立条件を満たす証拠として代用しません [2][15]。

7. 取るべき対応

1. 影響するLinuxに、修正を含むサポート対象のカーネル／ベンダービルドを適用する。 ホスト側の脆弱性は、ゲストのカーネルだけを更新しても修正されません。一方、ゲスト内Linux自身に入力経路がある場合は、そのLinuxの更新も別途判断します。個別コミットだけを無検証で取り込むのではなく、ディストリ／ベンダーが検証した更新を優先し、必要な再起動と動作確認を行います。CVEの確定待ちや後続の入力検証案を理由に、配布済み修正の適用を延期しません [3][10]。

2. 「インストール済み」と「実行中」を区別する。 ベンダーの修正済みビルド（Amazon Linuxのようにupstreamより小さいベース版数の場合がある）と、現在稼働しているカーネル／ライブパッチ状態を照合します [10][2]。

3. 後続の入口検証強化を監視する。 採用・配布された修正の内容に応じて追加更新を判断します（必ず追加更新が必要になると現時点で断定はしません）[3][8]。

4. 当面の露出低減は、構成別の補助策として検討する。 以下は公開された処理経路からの技術的検討であり、ベンダーが保証した共通の回避策ではありません。AWSも本件の回避策を示していません。

   • ゲスト由来トラフィックがNFQUEUE／xfrm／CHECKSUMターゲットの該当する完成処理を通らないようにできれば、その経路の露出は減らせます。ただし、モジュールの有無だけでは判断できず、他の完成処理が残らないかを確認します [3]。
   • ホストでのIPv4フラグメント処理を実際に避けられる経路は、その処理への露出低減になります。ただしMTU／MSSの調整だけで、悪意あるゲストが送る全パケットについて到達を防げるとは限らず、他の完成経路への対策にはなりません [3][15]。
   • チェックサムオフロードの無効化は、ゲスト側設定、virtio機能交渉、TAP側設定、物理NIC側設定で意味が異なります。TUNの実装注記にはゲストの交渉済み機能を把握していない旨があり、出力デバイスが処理しないチェックサムはソフトウェア処理へ回る場合があります。物理NIC等のスイッチを切ることと、不正な入力メタデータを拒否することは同義ではありません。 VMM・バックエンド・カーネルの版と実装を確認せず、「オフロードを無効にすれば安全」とは結論しません [26][29]。

   構成変更による通信断・性能低下等も評価し、修正適用の代替として扱いません [10]。

5. 多テナント基盤では可用性への影響も優先して評価する。 攻撃入力を処理するLinuxホストが停止すれば、その上のVM群に停止・利用不能が及びえます。重要業務への影響、異なる信頼レベルのワークロードの同居、更新時の退避・復旧手順を確認します。ただし、DoSが必ず情報漏えいやコード実行に先行するという予測ではなく、機密性・完全性の評価を省略する理由にもなりません [13][2]。

6. 記事化・資料化する場合：欠陥の所在は「Linuxカーネルのネットワークスタック」、実証された経路の一つは「ゲスト→ホスト境界侵害」と分けて書きます。CVSSのAV:L・PR:Nは、CNAが説明するmicroVM経路の前提とともに示します。研究者所有環境の実証を、すべての製品やベンダー本番環境での攻撃成立に拡張しません [2][15]。

8. 開示タイムライン

日付は原資料の表記を基本とします。時差が重要な項目にはUTC／PDT／JSTを併記しました。非公開の連絡については研究者の開示履歴として扱い、当時のメール原本を独立確認したものではありません。

日付（2026年）	出来事	出典
8月18日	Vercelが100万ドルのSandboxチャレンジを公表	Vercel公式 [14]
8月20日	研究者が初期のホストメモリ漏えい報告を提出	研究者の開示履歴 [15]
9月4日	カーネルセキュリティ窓口・netdevメンテナへ根本原因と候補パッチを非公開報告	研究者の開示履歴 [15]
9月7日	Michael S. Tsirkinが再現を確認、候補パッチを受領	研究者の開示履歴 [15]
9月19〜22日	netdevで公開パッチ投稿・改訂、レビュー範囲が拡大	netdev [15][7]
9月25日	CVE-2026-99999予約	CVEレコード [2]
10月7日	Tsirkinの改訂版ガード投稿。Willem de Bruijnの入口側検証案も投稿（翌8日に再提出要求。各案の最新状態は第4節の留保を参照）	netdev [15][31]
10月8日	net.gitに受理（patchwork bot）。Linus宛てpull要求送付	netdev／LKML [6][15]
10月9日	mainlineにマージ（af32da41、net-7.3-rc7）	torvalds/linux [5]
10月14日	Vercelがチャレンジ結果を公表	Vercel公式 [13]
10月15日	CVE公開（12:19 UTC＝21:19 JST）。修正を含むstableリリース（6.1.190・7.2.11の変更履歴で日付を確認）。AWS告知（10:30 PDT＝10月16日02:30 JST）。入口側修正のv2系列がnet-nextに投稿（受理・収録は※）	CVE／kernel.org／AWS／netdev [2][9][10][8]
10月16日	さくらインターネットが全社告知・クラウド対応告知、新規プロジェクト作成を一時停止	さくら公式 [16][17]

9. 参照

1. CVE Program：CVE-2026-99999 — https://www.cve.org/CVERecord/?id=CVE-2026-99999
2. CVE Program：公式レコード（JSON。公開日時・CNAのCVSS評価・修正版） — https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/99xxx/CVE-2026-99999.json
3. Linux修正コミット 6785011f8b16：ipv4: validate checksum_start before completing checksum — https://github.com/torvalds/linux/commit/6785011f8b16abf40b1e9d8b2e332232b3e68822
4. Fixes対象の原コミット（tun：2008年／packet：2010年） — https://github.com/torvalds/linux/commit/f43798c27684ab925adde7d8acc34c78c6e50df8.patch ／ https://github.com/torvalds/linux/commit/bfd5f4a3d605e0f6054df0b59fe0907ff7e696d3.patch
5. mainlineマージコミットとマージ通知（net-7.3-rc7） — https://github.com/torvalds/linux/commit/af32da41b0327b9c6a37856ba82b6760d6c8d10e ／ https://lkml.iu.edu/2610.1/02277.html
6. net.git受理通知／Linus宛てpull要求（10月8日） — https://lists.openwall.net/netdev/2026/10/08/618 ／ https://lists.openwall.net/linux-kernel/2026/10/08/1980
7. 研究者の初期パッチ系列（v4、9月20日） — https://lists.openwall.net/netdev/2026/09/20/11 ／ https://lists.openwall.net/netdev/2026/09/20/12 ／ https://lists.openwall.net/netdev/2026/09/20/13
8. 入力検証案・後続案の追跡用参照（※最新の受理・収録状況は未確認） — https://lists.openwall.net/netdev/2026/10/07/283 ／ https://lists.openwall.net/netdev/2026/10/08/670 ／ https://lkml.iu.edu/2610.1/18268.html ／ https://lkml.iu.edu/2610.1/19114.html
9. kernel.org：修正を含むリリースの変更履歴（6.1.190／7.2.11） — https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.190 ／ https://www.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.2.11
10. AWS Security Bulletin 2026-137-AWS — https://aws.amazon.com/security/security-bulletins/2026-137-aws/
11. Debian Security Tracker：CVE-2026-99999 — https://security-tracker.debian.org/tracker/CVE-2026-99999
12. Ubuntu Security：CVE-2026-99999 — https://ubuntu.com/security/CVE-2026-99999
13. Vercel：Findings from the $1M Vercel Sandbox challenge（10月14日） — https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge
14. Vercel：チャレンジ募集・構成・脅威モデル（8月18日） — https://vercel.com/blog/one-million-dollar-hacker-challenge-for-vercel-sandbox
15. pwn.ai：PwnEscape: Guest-to-Host KVM Escape（研究者の実証報告・予測） — https://pwn.ai/blog/pwnescape
16. さくらのクラウド：CVE-2026-99999への対応状況（10月16日） — https://cloud.sakura.ad.jp/news/2026/10/16/cve-2026-99999/
17. さくらインターネット：全社告知（10月16日17:00時点と記載） — https://www.sakura.ad.jp/corporate/information/announcements/2026/10/16/1968226051/
18. AWS：The Security Design of the AWS Nitro System — https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-nitro-system-journey.html
19. Firecracker：設計文書 — https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md
20. Google Cloud：Compute Engineのnested virtualizationとKVMベース基盤 — https://docs.cloud.google.com/compute/docs/instances/nested-virtualization/overview
21. Oracle：Virtualization（KVMとOCIに関する公表） — https://www.oracle.com/virtualization/
22. Microsoft：Hypervisor security on the Azure fleet — https://learn.microsoft.com/en-us/azure/security/fundamentals/hypervisor
23. gVisor：Networking Guide — https://gvisor.dev/docs/architecture_guide/networking/
24. Kata Containers：Architecture — https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md
25. Open vSwitch：DPDK vHost User Ports — https://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
26. Linuxカーネル文書：Checksum Offloads — https://docs.kernel.org/networking/checksum-offloads.html
27. Linuxカーネル文書：Universal TUN/TAP device driver — https://docs.kernel.org/networking/tuntap.html
28. Linux man-pages：packet(7) — https://man7.org/linux/man-pages/man7/packet.7.html
29. Linux v7.3-rc7：drivers/net/tun_vnet.h（TUNとゲスト機能交渉に関する実装・注記） — https://raw.githubusercontent.com/torvalds/linux/v7.3-rc7/drivers/net/tun_vnet.h
30. Linux CNAの告知（linux-cve-announce、10月15日。レコード本体は[2]） — https://lists.openwall.net/linux-cve-announce/2026/10/15/2
31. Michael S. Tsirkinの修正投稿（netdev、10月7日） — https://lists.openwall.net/netdev/2026/10/07/446
32. 初期報道（歴史的な説明・個別報奨額の報道に限定。現在の修正状況は一次資料を優先） — https://www.techzine.eu/news/security/144780/potential-vm-escape-puts-kvm-security-under-the-microscope/ ／ https://webhosting.today/2026/10/08/vercel-paid-50000-for-a-kvm-escape-that-has-no-cve-and-no-patch-every-vps-host-is-waiting-for-the-write-up/

---

本稿は筆者個人の分析であり、所属組織や各事業者の公式見解ではありません。基準日：2026年10月16日。※印は本稿で確認できなかった事項。公表情報と実行中カーネル・個別構成は異なるため、適用判断時には原典と自環境を再確認してください。