KVMエスケープ「Zapscape」公開。6年潜伏し三部作完結へ
LinuxのKVMに、ゲストVMからホストのroot権限を奪える脆弱性が見つかった。同一研究者による2か月で3件目のKVMエスケープとなる。
LinuxのKVMに、ゲストVMからホストのroot権限を奪える脆弱性が見つかった。同一研究者による2か月で3件目のKVMエスケープとなる。
shadow MMUに残った6年前のバグ
Linuxカーネルの仮想化機構KVMに、ゲストからホストへ脱出できる脆弱性「Zapscape」（CVE-2026-64561）が現地時間8月6日に公開された。
発見者はセキュリティ研究者のヒョンウ・キム（Hyunwoo Kim）氏。
脆弱性の原因は、KVM/x86のshadow MMU（メモリ管理ユニットのソフトウェアエミュレーション）にある解放後使用（use-after-free）だ。問題のコードは2020年7月にマージされたカーネル変更にさかのぼり、約6年間気づかれなかった。
shadow MMUは、ゲストVMが内部でさらに別のVMを動かす「ネスト仮想化」の際に使われる。ホストのKVMがゲストのページテーブルをソフトウェアでトラッキングする仕組みだ。
ページ回収がrootを渡す
KVMはshadow MMUページの総数にクォータを設けている。空きが足りなければ古いページを回収して再利用する。この回収処理の順序に問題があった。
ページフォールトの処理中、KVMはまず現在のMMUルートが古くないかをチェックし、その後にクォータ回収を走らせる。ところが回収の過程で、使用中のルートページが再帰的に無効化されるケースがあった。
無効化されたルートの下に新しい子ページが作られると、子ページは親の「無効」属性を引き継いだままアクティブリストに入る。
この子ページが解放された後もリストの参照が残り、次のshadow MMUページの挿入時にダングリングポインタへの書き込みが発生する。
キム氏のPoCはこの書き込みを起点に、カーネルアドレスの漏洩と任意のリストポインタ操作を経て、ホスト上で/Zapscapeというファイルをuid 0・権限0644で生成するところまでチェーンしている。
修正パッチ（コミット2abd5287f083）は7月21日にメインラインにマージ済みで、クォータ回収とルートの有効性チェックの実行順序を入れ替えることで問題を解消している。
クラウドのテナントが隣を落とせる
影響は2つの形で現れる。
1つ目はKVMエスケープだ。ゲスト内部の操作だけでホストカーネルを掌握できる。同一物理マシン上の他のテナントVMをすべて停止させることも、ホストのroot権限で丸ごと乗っ取ることもできる。パブリッククラウドでインスタンスを1つ借りれば、そこから同居する全テナントに手が届く。
2つ目はローカル権限昇格だ。RHELのように/dev/kvmがパーミッション0666（全ユーザー書き込み可）で設定されたディストリビューションでは、非特権ユーザーがこの脆弱性を使ってrootに到達できる。この場合はホスト側のVMMシステムコールも利用できるため、脅威はさらに大きくなる。
IntelとAMDで条件が異なる
Zapscapeが発動する条件はCPUベンダーによって異なる。
AMDでは制約がない。PoCが示すのは、ロングモードとPAEモードのNPT（ネスト用ページテーブル）で同じゲスト物理フレーム番号を持つページを重ねる手法だ。KVMのハッシュ検索が既存の子ページをルートとして再利用し、root_countを加算してしまう。
Intelでは、EPT（Extended Page Tables、拡張ページテーブル）のページウォーク長4と5の両方がL1（ゲスト）に公開されている場合にのみ発動する。片方だけでは子ページとルートのレベルが一致せず、同一ページの二重利用が成立しない。先に公開されたJanuscapeがIntelでも無条件に発動するのとは対照的だ。
三部作の完結
キム氏はこの脆弱性を「KVMエスケープ三部作」（The KVM Escape Trilogy）の最終章と位置づけている。
第1作のITScape（CVE-2026-46316）は6月に公開された、KVM/arm64では公に知られる初のゲスト脱出だ。vGIC-ITSの割り込み制御エミュレーションにある競合状態を突く。
第2作のJanuscape（CVE-2026-53359）は7月に公開された。x86のshadow MMUに16年間潜んでいた解放後使用で、IntelとAMDの両アーキテクチャで同一のPoCが動作する初の公開例とされる。キム氏はGoogleのkvmCTF報奨金プログラム（VMエスケープの上限は25万ドル）にゼロデイとして提出し、報奨金を受け取っている。
そして今回のZapscapeは、Januscapeと同じshadow MMUにありながら根本原因が異なる、別の脆弱性だ。
2か月で3件、arm64とx86の両方、QEMUではなくカーネル内のKVM本体。キム氏は今年5月にDirty Frag（ページキャッシュの権限昇格）も公開している。
| ITScape | Januscape | Zapscape | |
|---|---|---|---|
| CVE | CVE-2026-46316 | CVE-2026-53359 | CVE-2026-64561 |
| 公開 | 6月10日 | 7月6日 | 8月6日 |
| 対象 | KVM/arm64 | KVM/x86 | KVM/x86 |
| 根本原因 | vGIC-ITSの 競合状態 | shadow MMUの 解放後使用 | shadow MMUの 解放後使用 |
| 潜伏期間 | 約2年 | 約16年 | 約6年 |
| Intel条件 | 対象外 | 制約なし | EPT PWL4+5 の両方が必要 |
| AMD条件 | 対象外 | 制約なし | 制約なし |
| PoC | ホストパニック | ホストパニック | ホスト上に root権限で ファイル生成 |
パッチは出ている。問題は適用の速度
Zapscapeの修正は7月21日にメインラインへマージされ、Linux 7.2-rc5以降に含まれている。影響を受けるのは2020年7月8日のコミットf95eec9bed76から修正コミットまでの全バージョンだ。
ショーン・クリストファーソン（Sean Christopherson）氏がパッチを書き、パオロ・ボンジーニ（Paolo Bonzini）氏が投稿した。パッチの内容はシンプルで、is_page_fault_stale()の呼び出しをmake_mmu_pages_available()の後に移動するだけだ。クォータ回収がルートを無効化した場合、フォールトはRET_PF_RETRYでやり直される。
PoCは公開されているが、そのまま実際のクラウド環境で動く状態ではない。QEMU TCG上での動作検証用に設計されており、実環境への転用にはゲストカーネルモジュールへの移植とホストのkconfigへの適合が必要になる。ただしキム氏自身が、その移植は「難しい作業ではない」と明言している。
7月13日 パッチの協議 KVMメンテナーと協議。パッチを作成 7月21日 パッチがメインラインにマージ コミット2abd5287f083。処理順序を入れ替えて修正 8月1日 linux-distrosに提出 エンバーゴを5日間に設定 8月4日 CVE-2026-64561が割り当て 8月6日 エンバーゴ終了、全情報を公開 oss-securityに投稿。PoC・技術詳細文書を同時公開 |
KVMベースの仮想化環境を運用しているなら、修正パッチの適用状況を確認すべきだ。ネスト仮想化を有効にしていない環境では攻撃面は限定されるが、無効にしていても/dev/kvmが開放されたディストリでは権限昇格の経路が残る。
キム氏はFAQの最後に「続編はないことを願う」と書いた。shadow MMUのコードは、その願いに応えられるだろうか。
