PwnEscape（CVE-2026-99999）｜VMのパケットがホストを書き換える穴と確かめ方

はじめに

2026年10月15日、Linux カーネルの脆弱性 CVE-2026-99999（発見者の命名は「PwnEscape」）が公開されました。仮想マシン（ゲスト）の中から細工したパケットを送ると、ホスト側の Linux カーネルが、すでに検証を済ませた IPv4 ヘッダーを後から書き換えてしまう、という穴です。CNA（kernel.org）の深刻度は CVSS 9.3（Critical）。翌 10月16日には、さくらインターネットが VPS・レンタルサーバ・マネージドサーバの新規申込と、さくらのクラウドの新規プロジェクト作成を一時停止しました。

この記事のゴールは、自分が借りている VPS と、自宅で KVM や Docker を動かしている機械が「当事者」かどうかを自分で判断し、今日やることを決められるようになることです。そのために、ゲストのパケットがホストのカーネルに入る道（virtio-net と TAP）とチェックサムオフロードの基礎を押さえ、何が起きたのかを要点だけ確認したうえで、修正版と各ディストロの状況、事業者の対応、手元で確かめる手順へ進みます。状況は数日単位で動いているので、ディストロと事業者の状況は 2026年10月19日 午前3時（日本時間）時点の一次情報の表記で書いています。

🔌 1. virtio-net と TAP とは ── ゲストのパケットがホストのカーネルに入る道

仮想マシンの中の OS（ゲスト）は、本物の LAN カードを持っていません。代わりに virtio-net という「仮想化専用のネットワークカード」を使います。実在のチップを真似るのではなく、ゲストとホストが共有メモリ上のキューでパケットを受け渡すための、軽い取り決めです。KVM＋QEMU も、AWS Lambda や Vercel Sandbox が使う Firecracker のような軽量 VMM（Virtual Machine Monitor）も、ゲストのネットワークは virtio-net で見せるのが定番です。

ゲストが送ったパケットは、VMM が受け取ってホスト側の TAP デバイスに書き込みます。TAP は「プログラムが書き込んだイーサネットフレームを、LAN ケーブルから届いたかのようにホストのカーネルへ渡す」仮想インターフェースです。ここから先は、ホストのブリッジ、netfilter（iptables／nftables）、IPv4 のルーティングと、ふつうのネットワークスタックがそのパケットを扱います。

virtio-net は、パケット本体と一緒に小さな付帯情報も渡します。その一つが、次の節で扱うチェックサムについての依頼です。ゲストが書いた情報が、ホストのカーネルの処理にそのまま影響する。今回の入口はここです。

🧮 2. チェックサムオフロードとは ── 「あとで書き込んでおいて」という約束

TCP や UDP のパケットには、中身が途中で壊れていないかを確かめるためのチェックサムが付いています。本来は送り手の CPU がデータ全体を足し合わせて計算し、ヘッダーの決まった欄に書き込みます。データが大きいほど、この計算は CPU の時間を食います。

そこで多くの NIC は、「チェックサムは送り出す直前にこちらで計算して書き込む」機能を持っています。これがチェックサムオフロードです。カーネルはチェックサム欄を埋めないままパケットを NIC に渡し、「この位置から最後までを足し合わせて、結果をこの位置に書いておいて」という依頼を添えます。Linux のカーネルの中では、この「計算はまだ・あとで誰かが仕上げる」状態を CHECKSUM_PARTIAL と呼び、依頼の中身は計算を始める位置（checksum start）と結果を書き込む位置（checksum offset）の 2 つです。

速くなる理由は単純で、足し算を CPU から NIC の回路に移せるからです。大きな塊のまま扱って最後に分割する GSO／TSO と組み合わせると、分割後の一つひとつのチェックサムも NIC が計算するので、効果はさらに大きくなります。送り出すデバイスが計算できない場合や、途中でパケットを分け直す必要が出た場合は、カーネル自身が skb_checksum_help で計算を仕上げます。

仮想 NIC でも同じ仕組みが使えます。virtio-net の付帯情報には、この「start と offset」の依頼を入れられます。ゲストとホストは同じ物理マシンの上にいるので、ゲストの中で計算せずにホスト側（あるいはホストの実 NIC）に任せたほうが速いからです。

大事なのは、書き込む位置を決めるのは依頼する側だという点です。依頼者が自分のカーネルなら問題になりませんが、仮想化ではゲストがこの依頼を書けます。

🧭 3. 何が起きたか ── 検証を済ませたヘッダーに、後から書き込まれる

CNA（kernel.org）の CVE レコードにある評価の説明（CVSS の各項目に付けたシナリオ文）は、問題の経路を次のように書いています。悪意のある microVM が、送信するフレームにチェックサムの付帯情報を付ける。VMM はそれをホストの TAP に書き込み、パケットはホストの IPv4 処理に入る。IPv4 の断片化の処理の中で、チェックサムを仕上げる処理が呼ばれる。そしてこれは「ゲスト／ローカルの仮想デバイスの経路であり、インターネットからの受信経路ではない（not an Internet receive path）」と明記しています。

修正コミットのメッセージは、原因を一文でこう説明しています。「不正なチェックサムの付帯情報を持つパケットが IPv4 スタックに入ると、skb_checksum_help がネットワークヘッダーを壊し、さまざまな悪さを引き起こしうる（can corrupt the network header and cause a bunch of mischief）」。CNA のシナリオ文も、書き込みが起きるのはルーティングと検証が済んだ後の IPv4 ヘッダーの中で、後段のコードは書き換わった値をそのまま信じる、と説明しています。前の節の言葉でいえば、「あとで書き込んでおいて」という約束の書き込み先を、ゲストが検証済みのヘッダーの中に向けられた、ということです。

結果について、CNA のシナリオ文は 3 つを「実証された（demonstrated）」と書いています。

• 機密性（C:H）: 「This was demonstrated as continuous host-memory disclosure in guest-emitted packets.」── ゲストから出るパケットに、ホストのメモリの中身が継続的に漏れ出す
• 可用性（A:H）: 「Crafted guest packets were demonstrated to crash the physical host, taking down all sandboxes on it.」── 物理ホストがクラッシュし、その上のサンドボックスがすべて止まる
• 完全性（I:H）: 「Crafted guest packets using this flaw were demonstrated to execute commands with full administrator privileges on the host.」── ホスト上で、完全な管理者権限でコマンドが実行される

一方、AWS の告知は表現が控えめです。ゲスト内で特権を持つ者が細工したパケットでホストのカーネルのメモリを壊し、「ホストのメモリの開示またはサービス拒否につながりうる（could result in disclosure of host memory or a denial of service）」と書くにとどめ、コマンドの実行には触れていません。どちらの書き方でも、直す場所はホストのカーネルで同じです。

修正の位置づけも確認しておきます。コミットメッセージは「本来そうしたパケットを入れるべきではない」と書いたうえで、この修正を多層防御（defence in depth）として「チェックサムを仕上げる前にも確かめる」ものだとしています。入口でのより完全な検証は「今後出すが、まだ作業が要る」とのことです（第 5 節）。

🛡️ 4. 「KVM の穴」ではなく「ホストのネットワークスタックの穴」

AWS の告知の件名は「KVM ベースのハイパーバイザーに影響する」、oss-security への投稿の件名は「Guest-to-Host KVM Escape」です。たしかに越えられたのはゲストとホストの境界です。ただ、壊れていたのは CPU やメモリを仮想化する KVM ではなく、ホストの IPv4 処理の中のチェックサムの仕上げでした。

修正コミットの Fixes 行が「原因を持ち込んだ変更」として挙げているのも、KVM ではなく tun（TAP）と packet ソケットにチェックサムオフロードの依頼を受け付けるようにした 2 つの変更です。だから QEMU でも Firecracker でも、virtio-net と TAP でゲストのパケットをホストのカーネルに流す構成なら同じ道を通ります。AWS も影響を受ける構成として「Firecracker などの VMM を含め、virtio-net と KVM で仮想マシンを自分で管理している顧客」を挙げています。

CNA の CVSS ベクトル（AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）のうち、読み方の要になるのは次の 2 つです。

• PR:N（必要な特権なし）: CNA は、割り当てられた virtio-net で送信できるテナントのワークロードなら引き金のトラフィックを送れて、ホストの認証情報や権限、/dev/net/tun へのアクセスは要らない、と説明しています。特権を持つ VMM は、ゲストの出力を既存の TAP に転送しているだけです
• S:C（スコープ変更）: 付帯情報の出どころは信頼できない microVM なのに、壊されるのはホストのカーネルの状態です。CNA は、実証された漏えい・クラッシュ・管理者権限でのコード実行が「ゲストとホストの隔離の境界を越える」と書いています

CNA の 9.3 と Red Hat・SUSE の 8.8 の差は、この PR の評価だけです。ゲストの中で送信できることを「特権なし」と数えるか（CNA）、「低い特権あり」と数えるか（Red Hat）の違いで、評価する組織の立場の違いと読めます。AWS の「ゲスト内で特権を持つ者」という書き方も、ゲスト内の権限を条件として数える側の表現です。影響の大きさ（C／I／A がすべて High・S:C）の評価は一致しています（ワード解説は第 5 節）。

🩹 5. 修正と各ディストロの状況

修正はメインラインのコミット 6785011f8b16「ipv4: validate checksum_start before completing checksum」（作者は Red Hat の Michael S. Tsirkin、Google の Willem de Bruijn がレビュー）で、Linux 7.3-rc7 に入りました。netdev のツリーに取り込まれたのが 10月8日、Linus Torvalds のツリーに入ったのが 10月14日です。コミットメッセージ自身は、この修正を「多層防御（defence in depth）」と位置づけ、入口でのより完全な検証は「まだ作業が要る」と書いています。今後、追加の修正が来る可能性がある、ということです。

各 stable 系列の修正版は、CNA（kernel.org）の CVE レコードで次のとおりです。

影響を受ける範囲の書き方は、一次ごとに違います。CNA のレコードは「2.6.27 以降」、AWS の告知は「4.4 から 6.18 まで」です。どちらも「古い版から長く入っていた」ことに変わりはありません。

ディストリビューションが配るカーネルは、上の表の番号ではなくディストロ独自の版番号を持ち、修正は個別に取り込まれます。状況は 2026年10月20日に各一次で確認したものです。

Amazon Linux の修正カーネルは、AWS の告知で次のとおりです（この版以降）。

Amazon Linux Security Center の公開日は 10月1日〜10月12日で、CVE の公開（10月15日）より前です。公開前から事業者間で修正の調整が進んでいたことが分かります。

🏢 6. 事業者の対応

さくらインターネット ── 新規の受付を止め、既存は稼働を続ける

さくらインターネットは 10月16日（17:00 時点の情報として）、「当社サービスへの影響の有無および影響範囲の確認を進めています」と告知し、対象としてさくらのクラウド・さくらの VPS・さくらのレンタルサーバ・高火力 DOK・高火力 VRT を挙げました。各サービスで止めたものは次のとおりです。

どのページも、契約中のプランや作成済みのリソースは通常どおり稼働していること、再開時期は未定であること、対応としてホストメンテナンスを含むメンテナンスを行う可能性があることを書いています。VPS のお知らせは同日 18:10 にタイトルと内容が修正されましたが、「影響範囲については公開時から変更ありません」とのことです。さくらのクラウドのお知らせは 10月19日に更新され、「順次本件に関するメンテナンスを実施」し、対象の利用者には実施日の1週間前を目途にメールで日時と影響を案内する、と追記されました。2026年10月20日時点で、どのサービスも再開の告知はまだ出ていません。

止めたのが「新規」と「構成の変更」に集中している点は、読み方として筋が通っています。ホストのカーネルを入れ替えるまでは、新しい利用者や持ち込みのイメージを受け入れる口を絞る、という判断と思われます。また、専用サーバ PHY のように利用者自身が OS を管理するサービスについては、各 OS ベンダーの情報を確認して更新するよう案内しています。

AWS ── 管理サービスは影響なし、自前の KVM は更新を

AWS は Security Bulletin 2026-137-AWS で、Amazon EC2・AWS Lambda・AWS Fargate などの管理サービスは影響を受けず、利用者の対応は不要としています。対象は「virtio-net と KVM で仮想マシンを自分で管理している利用者（Firecracker のような VMM を使う場合を含む）」で、更新したカーネルをホストに入れて再起動するよう求め、回避策は「ない」と明記しています。影響の書き方も「ゲストの中で特権を持つ者が、ホストのメモリの漏えいまたはサービス停止につながりうる」と、CNA より一段控えめです。

Vercel ── 懸賞の中で見つかった 1 件

発端は Vercel が 8月18日に発表した、自社の Sandbox（Firecracker のマイクロ VM）の隔離を破る懸賞（賞金総額 100 万ドル）です。Vercel の 10月14日の報告によると、2 週間で 1,285 件の報告があり、Critical はこの Linux カーネルの 1 件だけ。顧客のデータが読まれたことを示す報告はなかったとしています。Vercel は「次のゼロデイを前提にする」として、ホストのカーネルを最新に保つこと、入れ子の仮想化の無効化、Firecracker の jailer による権限の絞り込みを挙げています。

そのほか（10月20日時点）

Microsoft の MSRC は、10月の Security Update Guide（CVRF）で 10月16日から CVE-2026-99999 を掲載しています。対象は Azure Linux 3.0 のカーネル（azl3 kernel 6.6.157.1-1 が「影響あり」）で、深刻度は Critical、修正ビルドとして 6.6.159.1-1 が示されています（10月18日に改訂 3.0）。Windows や Azure の管理サービスについての記載はありません。Google Cloud の Security Bulletins、JPCERT/CC の注意喚起、IPA の重要なセキュリティ情報には、CVE-2026-99999 の記載はまだありません。国内の他の VPS 事業者については、受付停止などの一次の告知を見つけられていません。

なお、oss-security への投稿によると、脆弱性の存在は公開前に X（旧 Twitter）で知られていたとされます。本記事は X の投稿を出典にしていません。

🏠 7. 自分の環境で確かめる

まず「当事者か」を分ける

今回の対策はホストのカーネルにしか効きません。そこで最初に、自分がどの機械のホスト管理者なのかを分けます。

VPS の「中」は、ゲストです。ゲストのカーネルを更新するのは良い習慣ですが、今回の穴はホスト側にあるので、それだけでは事業者のホストは直りません。

「ゲストを更新してもホストの対策にはならない」

自宅の Ubuntu 機で KVM の VM と Docker を同時に動かしている構成に当てはめると、直すべき場所は 1 か所です。

Docker のコンテナは自前のカーネルを持たず、ホストのカーネルの上で動きます。VM を動かしていない Docker 機は今回の VM 経由の経路の当事者ではありませんが、Red Hat は影響を与えうる者として「信頼できないゲスト」と並んで「ローカルの攻撃者」も挙げています。コンテナ機も、ホストのカーネルを修正版にする対象と考えておくのが無難です。

手順: カーネルの版を見る

uname -r      # 動いているカーネルの版
uname -v      # Debian ではパッケージ版（例: 6.12.113-1）がここに出る

素のカーネル（kernel.org の stable）を自分でビルドして使っているなら、uname -r を第 5 節の表と比べます。系列の番号が同じで、表の版以上なら修正済みです。

ディストロのカーネルは、番号を表と比べても判断できません。 たとえば Ubuntu 26.04 のカーネルは 7.0.0-30-generic のような独自の番号で、7.0 系は kernel.org の stable の表にそもそもありません。ディストロのカーネルは、次のようにディストロの告知で確かめます。

手順: Ubuntu

sudo apt update
apt list --upgradable 2>/dev/null | grep linux-image
ubuntu-security-status

• OK の条件: Ubuntu の CVE ページ（ubuntu.com/security/CVE-2026-99999）に、自分の版（26.04 なら resolute、24.04 なら noble）の行が「Released」で出て、その版以上の linux-image-* が入っていること。10月20日時点では全系列が「needed」で、まだこの状態にはなっていません
• 更新が来たら sudo apt upgrade で入れ、/var/run/reboot-required ができていれば再起動します。カーネルは再起動するまで入れ替わりません。再起動後に uname -r が新しい版になっていれば完了です
• 再起動の要否の見方と、Docker を動かしたまま更新した実例はUbuntu 26.04.1 更新の実録にまとめています。そのときはカーネルが更新対象に入らず再起動不要でしたが、今回はカーネルの更新なので再起動が要ります

手順: Debian

• bookworm は 6.1.190-1（DLA-4841-1）、trixie は 6.12.113-1（DSA-6568-1）以上なら修正済みです
• sudo apt update && sudo apt upgrade のあと再起動し、uname -v に出るパッケージ版が上の版以上になっていれば OK です

手順: VM を動かしているかの確認

lsmod | grep kvm          # kvm_intel／kvm_amd が出れば KVM が使える状態
virsh list --all          # libvirt を使っている場合。動いている VM の一覧
ip tuntap show            # TAP デバイスの一覧（VM のネットワークに使われる）

• virsh list に running の VM があり、ip tuntap show に tap のデバイスが並んでいれば、その機械は VM のホストです。ホストのカーネルの修正版が来たら、優先して入れて再起動します
• どれも出なければ、VM 経由の経路の当事者ではありません。通常の更新の流れで修正版を入れれば足ります

手順: Raspberry Pi 5

• cat /etc/os-release で OS を確認します。Ubuntu for Raspberry Pi なら、カーネルは linux-raspi で、10月20日時点では Ubuntu の他のカーネルと同じく「needed」です
• Raspberry Pi OS のカーネルは Raspberry Pi のリポジトリから配られ、Debian の DSA とは別の扱いです。修正版の告知は 10月20日時点では見つけられていません。sudo apt update && apt list --upgradable でカーネルのパッケージが来ているかを見ます
• Pi 5 で VM を動かしていなければ、VM 経由の当事者ではありません。修正版が来た時点で入れれば十分です

🔧 技術者の所感

✅ まとめ

• CVE-2026-99999（PwnEscape）は、ゲストが渡した情報をホストが検証の後に使ってしまう、ホストの Linux ネットワークスタックの穴。CNA の評価は CVSS 9.3、Red Hat・SUSE は 8.8
• 修正はメインラインの 6785011f8b16 と、5.10.272〜7.2.11 の各 stable 版。10月20日時点で Debian と Amazon Linux は修正版あり、Ubuntu・RHEL・SUSE は修正待ち
• さくらは新規の申込と構成の変更を止め、既存の契約は稼働を続けている。AWS の管理サービスは影響なし
• 悪用は未確認（KEV 未掲載）。研究者の Part 2 は未公開

この記事で、自分の機械がホストかゲストかを分け、何を見れば修正済みと言えるかまでたどり着けたはずです。次の一手は、自分がホスト管理者である機械を洗い出し、ディストロの修正版が出た日に更新と再起動を回すことです。Ubuntu の USN、Red Hat の errata、さくらの再開告知は、出しだい本記事に追記します。

よくある質問（FAQ）

Q. 借りている VPS の中でカーネルを更新すれば安全ですか？

A. 今回の穴はホスト側にあるので、VPS の中（ゲスト）の更新だけでは事業者のホストは直りません。ゲストの更新はふだんどおり続けつつ、ホストの対応は事業者の告知で確かめます。

Q. 実際に悪用されていますか？

A. 10月20日時点で、悪用は確認されていません。CISA の KEV（10月16日版）に掲載はなく、CISA の SSVC 評価も悪用「none」です。Red Hat の説明文には「KEV の active-exploit 事案として追跡」とありますが、KEV の掲載状況と食い違っており、根拠は公表されていません。

Q. 発見者の「Part 2」は出ていますか？

A. 10月20日時点では未公開です。発見者は Part 1 で、管理者権限の実行までの実証は自分たちのホストでの結果であり、事業者の本番環境の結果は開示の許可が出るまで分けておくと書いています。

Q. さくらの VPS を契約中です。止まりますか？

A. さくらの告知では、契約中のプランは通常どおり稼働しています。止まっているのは新規申込・スケールアップ・持ち込み ISO・クラウドへのマイグレーションです。対応としてホストメンテナンスを行う可能性があり、その場合は対象の利用者に改めて案内するとしています。

Q. Docker だけを動かしている自宅サーバーも対象ですか？

A. VM を動かしていなければ、VM 経由の経路の当事者ではありません。ただし Red Hat は影響を与えうる者として「ローカルの攻撃者」も挙げているので、ディストロの修正版が出たら通常どおり入れて再起動しておくのが無難です。

Q. 回避策はありますか？

A. AWS は「回避策はない」、Red Hat は「緩和策は用意できていない」としています。対策は修正版のカーネルを入れて再起動することです。

関連記事

• Linux カーネルの「AI パッチ洪水」｜CVE 2,000件の正体とメンテナの適応 — AI で見つかる脆弱性の「量」の側
• Ubuntu 26.04 LTS の新機能｜sudo の Rust 化・X11 廃止・GNOME 50 と既知問題 — 26.04（resolute）の基礎
• Ubuntu 26.04.1 更新の実録｜Docker 20コンテナを止めずに2分で完了 — 更新と再起動の要否の見方
• curl 8.23.0 で脆弱性24件を修正｜HTTP/2 の解放後使用と自分の curl の確かめ方 — 同じ週に AI の支援で見つかった、curl の High の 1 件

参考

• CVE-2026-99999（CVE レコード）
• 修正コミット 6785011f8b16
• AWS Security Bulletin 2026-137-AWS
• さくらインターネットの告知（2026年10月16日）
• さくらのクラウドの対応状況（2026年10月16日・10月19日更新）
• Microsoft Security Update Guide: CVE-2026-99999
• Ubuntu Security: CVE-2026-99999
• Debian Security Tracker: CVE-2026-99999