KVMのゲスト脱出脆弱性「Januscape」が発覚、完全な対処には2つのCVE適用が必須

LinuxカーネルのKVMハイパーバイザにおいて、16年間未検出だった深刻な脆弱性「Januscape」が2026年7月6日に公開された。この脆弱性を悪用されると、仮想マシン（VM）のテナントがホストOSを強制終了させたり、ホストのルート権限を奪取して他の全ゲストVMにアクセスしたりする恐れがある。影響はIntelとAMDの双方のCPUに及び、完全な修正には「CVE-2026-53359」と「CVE-2026-46113」の2つのCVEを適用する必要がある。

■16年越しの脆弱性「Januscape」の脅威

単一の仮想マシン（VM）をレンタルしているクラウドテナントが、同一の物理ホスト上で動作している他のすべてのVMを停止させたり、ホスト自体のルート権限を奪取してそのマシン上のすべてのゲストVMにアクセスしたりできる脆弱性が明らかになった。これは、LinuxカーネルのKVMハイパーバイザに16年間存在していたUse-After-Free（解放後メモリ使用）の脆弱性「Januscape」がもたらす最悪のシナリオである。この脆弱性は2026年7月6日に一般公開された。

主要なLinuxカーネルのメンテナンス対象ブランチには2026年7月4日にパッチが適用されたが、このセキュリティホールを完全に塞ぐには、相互に関連する2つのCVE（CVE-2026-53359と、その対となるCVE-2026-46113）を適用する必要がある。片方のみを適用した状態ではシステムが部分的に脆弱なまま放置されることになるが、この詳細は脆弱性そのものに比べて注目度が低い。

ホストのルート権限を完全に奪取するエクスプロイトコードは現時点では公開されていない。しかし、ゲストVMの内部から数秒から数分以内にホストを確実にパニック（強制終了）させる概念実証（PoC）コードは公開されており、攻撃者は共有インフラに対して即座にサービス拒否（DoS）攻撃を実行できる状態にある。この脆弱性を発見した研究者のHyunwoo Kim氏（@v4bel）は、管理された環境においてルートレベルで動作するエクスプロイトが存在することを確認している。

クラウドプロバイダー、CI/CDランナー、共有ホスティング環境、企業の仮想化クラスターなど、KVMベースのx86インフラを管理するシステム管理者は、CVSSスコアの割り当てを待つことなく、緊急のパッチ適用作業として対応すべきである。本記事の公開時点で、米国立脆弱性データベース（NVD）はCVE-2026-53359のスコアをまだ算出していない。

■1つのバグに2つの攻撃経路、想定以上の影響範囲

Januscapeには、混同しやすい2つの独立した攻撃シナリオが存在する。

1つ目は「VM脱出（VMエスケープ）」である。パブリッククラウドでインスタンスをレンタルした際のデフォルト状態である、内部でルート権限を持つ悪意あるゲストVMは、レースコンディション（競合状態）を誘発してホストカーネルのシャドウページの状態を破壊できる。これを巧妙に操作することで、ゲストVMはホストに攻撃者が意図したメモリ領域をマッピングさせることが可能となり、これが完全なVM脱出の基盤となる。この操作を行わずにレースコンディションを発生させた場合でも、カーネル内部の整合性チェック（pte_list_remove内）が作動してホスト全体がクラッシュする。Kim氏のPoCでは、このクラッシュ経路が数秒から数分以内に確実に機能することが示されているが、完全なコード実行経路のコードは公開されていない。

2つ目の経路は「ローカル権限昇格」であり、これは当初報じられた「クラウドテナント」という枠組みよりも広い影響を及ぼす。Red Hat Enterprise Linux（RHEL）およびその下流の再構築版（RHEL EL8、EL9、EL10、およびCloudLinux 8、9、10）では、KVMデバイスノードである「/dev/kvm」がデフォルトで全ユーザーにアクセス可能（パーミッション 0666）になっている。つまり、シェルアカウントを持つ権限のないローカルユーザーであれば、デバイスを直接開いて使い捨てのVMを作成し、同じ潜在的バグを誘発させることができる。この際、ホストが実際にゲストワークロードを実行している必要はない。侵害されたWebアプリケーション、不正なプロセス、または他の脆弱性からの横展開（ラテラルムーブメント）の踏み台などがすべてこれに該当する。ゲストVMを1つもホストしたことがない共有Linuxサーバーであっても、脆弱なカーネルを実行し、デフォルト権限の未パッチの「/dev/kvm」が存在していれば、依然として危険にさらされている。

このバグは、Intel（VMX/EPT）とAMD（SVM/NPT）の双方のCPUで発生する。なお、ARM64ホストは影響を受けない（Kim氏が2026年6月に公開した「ITScape」は、これとは別のKVM/arm64に関する問題である）。

■16年間見過ごされたシャドウページングの盲点

このバグが存在する理由を理解するには、KVMがゲストVMのメモリアドレスをホストの物理アドレスに変換する、根本的に異なる2つの方法を知る必要がある。

現代のハードウェアにおけるデフォルトは「ハードウェア支援型ページング」である。2006年から2007年頃に最初のハードウェア仮想化支援機能とともに導入されたIntelのEPT（Extended Page Tables）やAMDのNPT（Nested Page Tables）により、CPUが直接アドレス変換を処理できるようになった。ハードウェア支援型ページングが利用可能で、ネストされた仮想化（Nested Virtualization）が使用されていない場合、KVMはこの処理をハードウェアに委ねるため、シャドウページングのコードはほぼ休止状態になる。

しかし、ネストされた仮想化が有効な場合（ゲストVM自体がハイパーバイザを実行し、独自のサブゲストを管理している場合）、KVMは処理を完全にハードウェアに委ねることができない。プライマリゲスト（L1）が自身のゲスト（L2）に対してハイパーバイザとして動作しているため、ホスト（L0）はL1のためにソフトウェアで第2レベルのアドレス変換をエミュレートしなければならない。これにより、KVMはシャドウページングサブシステムの使用を強制される。ホストは、ゲストのメモリレイアウトをミラーリングするソフトウェアコピー（「シャドウ」ページテーブル）を維持する。

シャドウページングは古いコードである。Intel EPTよりも数年前に作られたものであり、現在では主にネストされた仮想化の互換性のために維持されている。そのため、ハードウェアページング経路に比べて開発時の積極的な検証が行われにくく、ファジング（脆弱性検出テスト）の対象となる機会も少なかった。この組み合わせが、16年前の設計ミスが隠され続ける環境を生み出した。

バグが存在する具体的な関数は「kvm_mmu_get_child_sp()」であり、KVMがゲストメモリの一部を追跡する必要がある場合に、シャドウページテーブル構造を取得または再利用する処理を行う。KVMが再利用可能な既存の構造を探索する際、そのチェックはゲストフレーム番号（gfn、表されるアドレス）のみを比較しており、ページが直接マッピングであるか、ゲストページテーブルの間接的なシャドウであるかを記録する構造体フィールドである「role」を検証していなかった。

ゲストがページディレクトリのエントリ（PDE）を変更してマッピングを切り替え、その後にメモリスロットを削除すると、クリーンアップルーチンは逆マッピングされたすべてのエントリを検出して破棄することになっている。これに関連する脆弱性「CVE-2026-46113」は、変更されたPDEがリーフ（末端）のシャドウページを指しているケースに対処したものだった（2026年5月に修正済み）。一方、今回のJanuscape（CVE-2026-53359）は非リーフのケースである。PDEが非リーフページを指している場合、そのシャドウページのゲストフレーム番号は一致する（同じゲストページテーブルであるため）が、roleが異なる。再利用チェックは「gfnが一致するため再利用する」と判断し、誤ってすでに解放されたページを返してしまい、その後のクリーンアップルーチンが解放済みメモリに書き込みを行う。これが、CVE-2026-53359の中核にあるUse-After-Freeである。

攻撃者が精密なタイミング制御を行うことで、再割り当て後に解放された構造体が配置される場所を操作し、メモリ破壊を制御された書き込みプリミティブに変換し、そこからホスト上での完全なコード実行へとつなげることができる。Kim氏のPoCはサービス拒否（DoS）の経路を実行するものであり、ルート実行経路はGoogleの「kvmCTF」プログラムを通じて提出されたもので、一般には公開されていない。

KVMのメンテナであるPaolo Bonzini氏が作成し、2026年6月19日にメインラインにマージされた修正パッチは、「kvm_mmu_get_child_sp()」内のgfnチェックと並んで「role.word」の比較を追加している。これにより、フレーム番号とroleの双方が一致する場合にのみシャドウページが再利用されるようになった。わずか1つの比較処理を追加することで、16年間にわたる脆弱性が解消された。

■なぜ2つのCVEが必要なのか：片方だけでは不十分な理由

この点はJanuscapeに関する報道において十分に強調されておらず、管理者がパッチの適用状態を確認する上で直接的な運用上の影響を及ぼす。

CVE-2026-53359（コミット：81ccda30b4e8）が主要な修正であり、Januscapeが突く非リーフのrole不一致経路を塞ぐ。一方、CVE-2026-46113（コミット：0cb2af2ea66a）は、同じコード経路におけるリーフのgfn不一致のケースを塞ぐ補完的な修正であり、2026年5月に出荷されている。

これら2つのパッチは、同じシャドウページ再利用ロジックにおける、関連しつつも異なる障害モードに対処している。CVE-2026-46113を適用せずにCVE-2026-53359のみを適用した場合、リーフケースの経路が脆弱なまま残る。逆に、CVE-2026-46113のみを適用した場合は、非リーフケースであるJanuscape自体が完全に未対処のままとなる。この脆弱性クラスを完全に修正するには、実行中のカーネルに両方のコミットが存在している必要がある。

ディストリビューションのバックポートでは、異なるカーネルバージョン番号の下で両方のパッチが取り込まれている可能性があるため、「uname -r」の確認だけでは不十分である。管理者は、パッケージの変更履歴（changelog）にコミット「81ccda30b4e8」（CVE-2026-53359）とコミット「0cb2af2ea66a」（CVE-2026-46113）の両方が含まれていることを確認する必要がある。

KernelCareのライブパッチを使用しているシステムでは、「kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'」を実行し、両方が表示されることを確認する。

■テナントへのネストされた仮想化の提供は「セキュリティ上の意思決定」に

多くの報道で欠落している最も運用上重要な意味合いは、クラウドテナントに対してネストされた仮想化を提供するかどうかの決定が、もはや単なる「機能の可用性」の問題ではなく、「セキュリティアーキテクチャ」の問題になったという点である。

Januscapeのゲストからホストへの脱出経路はすべて、ホスト上でネストされた仮想化が有効になっていることを要求する。デフォルトでハードウェア支援型ページング（EPTまたはNPT）を使用しているホストであっても、テナントが自身のVMでネストされた仮想化を有効にすると、ホストはレガシーなシャドウMMUコードの使用を強制される。そのコード経路では、2026年だけでもすでに2つのUse-After-Free脆弱性（5月のCVE-2026-46113と7月のCVE-2026-53359）が記録されている。Kim氏は、このバグクラスにおいて「さらなる亜種や後続の脆弱性が予想される」と指摘している。

インフラ事業者は、ネストされた仮想化へのアクセスが必要なユーザーを正式にレビューし、それを必要とするテナントと不要なテナントを隔離し、そのユースケース（VM内でのKubernetesテスト、ネストされたCI環境、仮想化された開発クラスターなど）が、信頼できないゲストに対してレガシーなシャドウページング経路を公開するリスクに見合うかどうかを明示的に評価すべきである。ネストされた仮想化が必要ない環境では、ハイパーバイザレベルでこれを無効にすることで、カーネルアップデートを適用する前であっても、ゲストからホストへの脱出攻撃面を完全に排除できる。

ただし、これにより全ユーザーにアクセス可能な「/dev/kvm」を持つシステムにおけるローカル権限昇格のリスクが排除されるわけではない。この経路はネストされた仮想化を必要としないため、ゲストVMを実行していないホストであっても「/dev/kvm」の権限を監査し、書き込み権限が不要であればアクセスを制限する必要がある。

■パッチ、ライブパッチ、および今すぐ確認すべき事項

上流の修正は、2026年7月4日にメンテナンス対象のすべてのLinux安定版および長期サポート（LTS）ブランチに適用された。

・7.x 安定版：7.1.3
・6.18.x：6.18.38
・6.12.x（LTS）：6.12.95
・6.6.x（LTS）：6.6.144
・6.1.x（LTS）：6.1.177
・5.15.x（LTS）：5.15.211
・5.10.x（LTS）：5.10.260

Debianは7月5日に「DSA-6381-1」を発行し、testing（trixie）およびunstable（sid）ブランチに対応した。stable（Bookworm）およびoldstable（Bullseye）向けのパッチは、7月8日時点で保留中となっている。

SUSEおよびopenSUSEはこの問題を「重要（Important）」と評価し、SUSE Linux Enterprise 15 SP7およびLeap製品ラインの大部分でパッチが品質保証（QA）段階にある。

AlmaLinux、Rocky Linux、Oracle LinuxはRHELから再構築されているため、そのカーネル修正に従い、対応するRed Hatのアドバイザリに追随する予定である。

CloudLinuxは、CL7hおよびCL8向けの修正パッチをベータ/テストチャネルでリリースし、クラッシュと基礎となるメモリ破壊の両方の再現を独自に確認した。CL9およびCL10向けのAlmaLinuxカーネルは、AlmaLinuxのテストリポジトリに存在している。

再起動なしでパッチを適用できるKernelCareのライブパッチは、各ディストリビューション向けに順次展開されている。7月7日時点でメインフィードにあるのは、AlmaLinux 10、RHEL 10、Oracle Linux 10、Rocky Linux 10、およびUbuntu 22.04（Jammy）である。テストフィードにはUbuntu 24.04（Noble）があり、EL8やEL9などは準備中となっている。CloudLinux 8 LTSおよび9 LTSのTuxCare Extended Lifecycle Support（ELS）顧客には、「kernel-lts」パッケージを通じて修正が提供される。

推奨される対応手順は以下の通りである。

1. カーネルアップデートを即座に適用する。2つのコミット（CVE-2026-53359用の81ccda30b4e8と、CVE-2026-46113用の0cb2af2ea66a）が適用されていることを確認する。ディストリビューションのバックポートでは異なるバージョン番号で修正が取り込まれている可能性があるため、uname -rだけに頼らず、パッケージの変更履歴を確認すること。

2. KernelCareを実行している場合は、次のコマンドで両方のCVEが適用されているか確認する：「kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'」

3. カーネルの即時アップデートが不可能な場合は、カーネルモジュールのパラメータを使用してネストされた仮想化を無効化する。
・Intelホストの場合：echo "options kvm_intel nested=0" > /etc/modprobe.d/kvm_intel.conf
・AMDホストの場合：echo "options kvm_amd nested=0" > /etc/modprobe.d/kvm_amd.conf

4. ゲストVMを実行していないホストにおいて「/dev/kvm」の権限を監査する。全ユーザーへの書き込み権限が不要な場合は制限する。

CVSSスコアが確定するのを待たずに行動を起こすべきである。ホストをパニックさせる実証コードが公開されており、未公開ながらルート権限奪取エクスプロイトの存在が確認されていること、そして影響を受けるインフラがx86上のすべてのLinuxベースのクラウドおよび仮想化環境に及ぶことから、即時の対応が強く推奨される。

■10週間で3つのKVMエクスプロイトを公開したKim氏の警告

Januscapeは、Hyunwoo Kim氏が約2ヶ月の間に公開した3つ目のLinuxカーネルエクスプロイトであり、それぞれ異なるサブシステムを対象としている。

2026年5月、同氏は「Dirty Pipe」や「Copy Fail」と同じ系統のページキャッシュ書き込み脆弱性チェーンである「Dirty Frag」（CVE-2026-43284 / CVE-2026-43500）を公開し、主要なLinuxディストリビューションの大部分で決定論的なルートアクセスが可能であることを示した。

2026年6月には、KVM/arm64における初のゲストからホストへの脱出を実証した「ITScape」（CVE-2026-46316）を公開した。これは仮想割り込みコントローラ（vGIC-ITS）におけるレースコンディションとUse-After-Freeを悪用したもので、同アーキテクチャのカーネル内仮想化スタックで記録された初の脱出事例となった。

そしてJanuscapeはx86における対応策であり、IntelとAMDの双方で同じトリガーが機能する。共通のコード経路から両アーキテクチャに影響を与えることが確認された、初の一般公開されたKVMゲスト脱出エクスプロイトとなった。

1人の研究者が10週間の間に3つの異なるサブシステムで3つの異なるバグクラスを発見したという事実は、それ自体が重要なシグナルである。Kim氏はITScapeの公開後、「KVMのMMUコードにおいて、さらなる亜種や後続の脆弱性が予想される」と述べていた。2つのCVEと1つの完全な脱出事例の公開を経て、その予測は現実のものとなっている。シャドウMMUのコードは、今回のJanuscapeのパッチ適用サイクルを超えて、セキュリティコミュニティによる継続的かつ専門的な監視が必要である。

■VM脱出とクラウドの分離保証

VM脱出の脆弱性は、特定の機能ではなくクラウドの根本的な前提を攻撃するため、クラウドセキュリティにおいて極めて重大な位置を占める。共有クラウドインフラのビジネスモデルは、同一の物理ハードウェア上で動作する複数の顧客のワークロードが互いに隔離されているという保証の上に成り立っている。ゲストVMがホストのカーネルメモリにアクセスできるようになれば、その保証は崩壊し、同一の物理マシン上のすべてのテナントが影響範囲に入る。

VM脱出は非常にまれである。公開されているハイパーバイザの脆弱性研究の大部分は、コードの露出面が広く研究の歴史が長いQEMUユーザー空間エミュレーション層を対象としている。Januscapeが注目に値するのは、QEMUを一切介さず、エクスプロイトチェーン全体がLinuxカーネルのKVMサブシステム内に存在するためである。これは、QEMUを完全にバイパスするカスタムVMM（仮想マシンモニター）スタックを使用している大規模なクラウドプロバイダーにとっても脅威となることを意味する。

このバグが16年間も存続していた事実は、特定のCVEを超えた構造的なリスクを示している。後方互換性のために維持されているレガシーなコード経路（ネストされた仮想化をサポートするために残されたシャドウページングなど）は、ハードウェアで加速された主要なコード経路に比べて、積極的なセキュリティ検証を受けにくい可能性がある。この検証のギャップは個別の脆弱性とは無関係に悪用可能であり、コミュニティがこれらの古いサブシステムに対してより体系的な検証に取り組むまで、Januscape以降も存続し続けるだろう。

■注目ポイントQ&A

●仮想マシンを実行していなくても、Januscapeの影響を受けますか？

影響を受ける可能性があります。Red Hat Enterprise Linux（RHEL）EL8、EL9、EL10、およびその下流の再構築版（CloudLinux、AlmaLinux、Rocky Linux、Oracle Linuxなど）では、KVMデバイスノード「/dev/kvm」がデフォルトで全ユーザーにアクセス可能な権限になっています。そのため、システムがゲストVMをホストしていなくても、権限のないローカルユーザーがこのデバイスを開いてバグを誘発し、ホストをクラッシュさせることが可能です。脆弱なカーネルを実行し、全ユーザーにアクセス可能な「/dev/kvm」が存在する共有サーバー環境では、ローカル権限昇格の危険性があるものとして対処（デバイス権限の制限およびカーネルパッチの適用）する必要があります。

●なぜ1つではなく、CVE-2026-53359とCVE-2026-46113の2つのCVEを適用する必要があるのですか？

これら2つのCVEは、KVMのシャドウページ再利用ロジック（kvm_mmu_get_child_sp関数内）における、関連しつつも異なる障害モードに対処しているためです。2026年5月に修正されたCVE-2026-46113は、変更されたページディレクトリのエントリ（PDE）がリーフ（末端）のシャドウページを指し、ゲストフレーム番号が一致しなくなるケースを修正しました。一方、Januscape（CVE-2026-53359）は非リーフのケースを修正するもので、フレーム番号が一致していてもroleが一致しない場合に再利用を防ぎます。それぞれ異なるコード経路を修正するため、片方だけではもう一方の脆弱な経路が残されてしまいます。

●Januscapeは、QEMUの代わりに独自のVMMスタックを使用しているクラウドプロバイダーにも影響しますか？

はい、影響します。これがJanuscapeの最も重要な特徴の1つです。過去に報告された多くのKVM脆弱性は、KVMとQEMUユーザー空間エミュレータとの相互作用を悪用するものであったため、QEMUを使用しないカスタムVMMを実行している主要なクラウドプラットフォームは影響を受けないことがありました。しかし、JanuscapeはQEMUを必要としない、純粋なカーネル内のKVMバグです。ネストされた仮想化が有効になっているx86 Linuxホストであれば、ユーザー空間でどのようなVMMがゲストを管理しているかに関わらず、すべて影響を受けます。

●Januscapeは現在、野外で実際に悪用されていますか？

本記事の公開時点で、悪意のあるアクティブな悪用事例は確認されていません。この脆弱性は、Googleの「kvmCTF」バウンティプログラムを通じて実証されたものです。公開されているPoCはホストを強制終了させるDoS経路のみを実行するものであり、ルート権限を奪取する完全なエクスプロイトは研究者によって確認されているものの、公開はされていません。また、linux-distrosメーリングリストを通じた責任ある開示プロセスにより、2026年7月6日の情報公開前に各ディストリビューションがパッチを準備することができました。ただし、ホストを強制終了させるPoCはすでに公開されているため、速やかなパッチ適用が必要です。

元記事: Linux KVM Guest-to-Host Escape Hits Both Intel and AMD: Two CVEs Required