Januscape(CVE-2026-53359): 16年潜在したLinux KVMのShadow MMU脆弱性、Intel/AMD両対応のGuest-to-Host Escape

Linux KVMのShadow MMUエミュレーション部分に、ゲストVM内部からの操作だけでホストカーネルのメモリ管理構造を破壊できるuse-after-free脆弱性CVE-2026-53359(通称Januscape)が発見され、2026年7月4日に安定版カーネル各系列で修正が配布されました。発見者は韓国のセキュリティ研究者Hyunwoo Kim氏(@v4bel)で、Kim氏によれば公表時点で「Intel VMXとAMD SVMの両方でトリガー可能な、最初の一般公開されたKVMゲスト・ホスト脱出脆弱性研究」に位置付けられます。潜在期間は約16年(2010年8月のcommit `2032a93d66fa`から2026年6月のcommit `81ccda30b4e8`まで)で、影響は公開PoCによるホストカーネルパニック(DoS)から、Kim氏が保留している完全版exploitによるホスト側root権限でのコード実行(RCE)まで広がります。

Januscapeが実務的に深刻なのは、カーネル内蔵のKVM(in-kernel KVM)のバグでありQEMU等のユーザ空間VMMを経由しない点、Intel/AMD双方の実CPU上で同じロジックを介して発火する点、そしてGCPやAWSのようなマルチテナントx86パブリッククラウドも、ネスト仮想化(nested virtualization)を露出する構成では想定脅威モデルに含まれ、そこで「ゲスト内でのroot権限確保」と組み合わさると攻撃面が開く点です。同脆弱性はKim氏が過去2か月に相次いで公表した3件の重大なLinuxカーネル脆弱性の3件目に位置し、5月のDirty Frag(CVE-2026-43284/CVE-2026-43500、page-cacheチェーン)、6月のITScape(CVE-2026-46316、KVM/arm64の最初の公開ゲスト脱出)に続く形で、今回はx86 KVM側のゲスト脱出研究として公表されました。修正は既に上流にマージされており、対応は主要ディストロで進んでいますが、パッチ確認はカーネルバージョンではなく修正コミット`81ccda30b4e8`のバックポート有無で判定する必要があります。

Januscape脆弱性の全体像
KVMとShadow MMUの位置付け
攻撃発火の前提条件
脆弱性の技術的な原理
16年間気づかれなかった理由
Hyunwoo Kim氏による一連のLinuxカーネル脆弱性研究
修正確認と実務対応
一次情報・公式情報
参考情報

Januscape脆弱性の全体像

本脆弱性はカーネル内KVMのShadow MMUエミュレーションに存在するuse-after-free型メモリ安全性欠陥で、公表時点で実世界での悪用は報告されていません。Google kvmCTFへの0-day submissionとして使用されており、修正コミットとともに責任開示プロセスを経てoss-securityで技術詳細が公表されました。

項目	内容
CVE番号	CVE-2026-53359
通称	Januscape
脆弱性クラス	Use-after-free in KVM Shadow MMU emulation
影響サブシステム	Linux KVM/x86(in-kernel)、Intel VMXおよびAMD SVMの両アーキテクチャで発火
ARM64への影響	Januscape単体では影響なし(別途ITScape/CVE-2026-46316への対処が必要)
発見者	Hyunwoo Kim氏(@v4bel)
公表日	2026年7月6日頃(oss-securityでの詳細公表)
影響コミット範囲	2032a93d66fa(2010年8月1日、Linux 2.6.36系相当)〜81ccda30b4e8(2026年6月16日)
潜在期間	約16年
修正安定版	Linux 7.1.3 / 6.18.38 / 6.12.95 / 6.6.144 / 6.1.177 / 5.15.211 / 5.10.260(2026年7月4日リリース)
攻撃前提条件	ゲスト内root権限 + ホストのネスト仮想化有効化 + ゲストからのカーネルモジュールロード
公開PoCの効果	ホストkernel panic(サービス停止/同一物理ホスト上の他テナントVMも巻き込む可能性)
未公開exploitの効果(Kim氏保留)	ホスト側root権限でのコード実行(RCE)
副次的影響	/dev/kvmが0666のディストロ(RHEL等)では非特権ユーザからのLPEも可能
CVSSスコア	TenableのCVEデータベースではCVSS v3.0 Base Score 7.8(High、ベクターCVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)、CVSS v2 Base Score 5.6(Medium)、EPSS 0.00176と表示(2026年7月時点)。NVD本体の評価表示は記事執筆時点で要確認。
kvmCTFでの位置付け	Google kvmCTFへの0-day submissionとして採用(同プログラムは最大$250,000の懸賞)

KVMとShadow MMUの位置付け

KVMはLinuxカーネル内蔵のハイパーバイザ機構で、Linuxカーネル自身がType 1相当のハイパーバイザとして動作し、その上にゲストVMを乗せる構造を持ちます。マルチテナントを扱う代表的なパブリッククラウドの多くがKVMを基盤に採用しており、Googleは自社のkvmCTFプログラムでKVMをAndroidとGoogle Cloudを支える基幹コードと位置付けています。KVMのバグはQEMU脱出のような伝統的な仮想化脱出と異なり、ユーザ空間VMMの実装に関係なく発火するため、独自の仮想化スタックを持つ大規模クラウドにも同じ脅威として作用します。

Shadow MMUは、ハードウェア支援型の第二段階ページング(Intel EPT、AMD NPT)が利用できない状況で、ゲストのメモリレイアウトをホスト側でソフトウェア的にミラーしてページテーブルを維持する仕組みです。現代のホストの多くはEPTまたはNPTを既定で使うため、Shadow MMUは表向き休眠状態に見えますが、ネスト仮想化が有効化されるとKVMはこのレガシーコードパスに戻されます。Januscapeが問題となる根本理由がここにあり、モダンハードウェア機能で守られているように見える環境でも、ゲストが仮想化を入れ子で使う操作を許容している時点で16年物のレガシー経路が実際の攻撃面として復活します。

攻撃発火の前提条件

Kim氏のREADMEおよびoss-securityへの詳細開示によれば、Januscapeがゲスト側から発火するには次の条件がすべて揃う必要があります。

ゲスト内でのroot権限:ゲスト内でカーネルモジュールをロードするためにゲストkernel権限が必要です。パブリッククラウドで割り当てられるインスタンスは通常ゲストroot前提で貸与されるため、この条件は攻撃者にとって自然に満たされます。ゲスト内での通常ユーザ権限しかない状況では、別途Dirty FragのようなLPEと連鎖する必要があります。
ホスト側のネスト仮想化有効化:ホストが`kvm_intel.nested=1`または`kvm_amd.nested=1`(既定は多くのディストロで有効)でネスト仮想化を露出している必要があります。この条件下でShadow MMUのコードパスが実際に走ります。
QEMU非依存:本脆弱性はカーネル内KVMコードに存在するため、QEMUのエミュレーションが介在するかどうかに関係なく、ゲスト側の操作だけでホスト側KVMの該当コードパスを発火させられます。独自仮想化スタックを持つクラウド事業者も同じ脅威モデルに含まれます。
ゲストからのカーネルモジュール投入:ゲスト内から特定のVMX/SVM操作を行うカーネルモジュールをロードすることで、Shadow MMU側の状態遷移を短時間のうちに繰り返し発生させ、use-after-freeを再現します。公開PoCでは、Kim氏本人の説明によれば「数秒から数分」程度のレース発火時間が想定されます。

公開PoCの動作は`arch/x86/kvm/mmu/mmu.c`内の`pte_list_remove`でホストがカーネルBUGを起こす形で観察でき、これは実装的にはホストKVMがすでに解放したShadow page構造への参照を残したまま追加操作を行い、メモリ整合性検査に引っかかって強制停止する挙動として現れます。この段階だけでも、同一物理ホスト上に載っている他のテナントVMをすべて巻き添えにする形のホスト全体DoSが成立します。

脆弱性の技術的な原理

ゲストVMを動かすため、KVMはゲストの物理メモリレイアウトをミラーする「Shadow page」と呼ばれる自己管理のページテーブル群を保持します。KVMは新しいShadow pageが必要になったとき、まず再利用可能な既存Shadow pageを探しに行き、キャッシュヒットすればそれを流用します。この再利用ルックアップが従来はゲスト側のフレーム番号(guest frame number)のみで一致判定を行っていた点が、Januscapeの根本原因です。

Shadow pageには「ページの役割(role)」というメタデータが付随し、同じフレーム番号を指していても、そのページテーブルが果たすべき機能(通常ページ用、ページテーブル用、EPT/SPT両モードの区別など)は異なる場合があります。フレーム番号だけで再利用してしまうと、ある文脈で解放されたShadow pageが、別の役割を要求する新規リクエストに割り当てられ、結果として矛盾した状態のページテーブル構造がホストカーネル内で参照可能になります。この矛盾を意図的に誘発すると、既に解放された`pte_list`ノードへの参照が生き残り、後続のノード削除処理でuse-after-freeが発生する構図です。

修正コミット`81ccda30b4e8`ではこのShadow page再利用ロジックが厳格化され、guest frame numberとpage roleの両方が一致した場合にのみ再利用する形へと変更されました。差分としては最小限のロジック変更ですが、16年物の設計上の穴を塞ぐ変更で、Kim氏はこれを「reuse-by-address」的な旧世代の前提が現代のShadow MMU設計と整合しなくなっている例として示しています。

16年間気づかれなかった理由

Januscapeの背景で頻繁に指摘されるのは、16年間気づかれなかったこと自体の重みです。潜在期間はLinux 2.6.36系まで遡り、この間にKVMはIntel/AMD双方で本番仮想化基盤に採用され、Androidデバイス、Google Cloud、AWS、その他多くの環境で運用されてきました。

なぜこれほど長期間発見されなかったのか、複数の構造的要因が同時に働いていた面があります。Shadow MMUはハードウェア支援型ページング(EPT/NPT)の普及によって表向き利用頻度が減少し、fuzzingや監査の投資対象としても優先度が下がっていました。しかしネスト仮想化は依然として広く提供され続けており、その裏でShadow MMUコードパスは実運用中のコードとして生存していました。この「使われていないように見えて、実は攻撃者にとって開いている経路」という状態が、監査の死角を生み出しました。

また、Shadow pageの再利用ロジックは実装的にはKVMコアの深部にあり、正常運用時にはフレーム番号だけの照合でも問題が顕在化しません。挙動異常が現れるのは、攻撃者が意図的にShadow pageのライフサイクルを操作したときだけで、通常のワークロードや自然な負荷ではまず引き当てられない状態でした。仮想化コアの複雑性がそのままメモリ安全性検証の難易度に直結する構造的な問題で、Januscapeは同種のレガシーコード内在型脆弱性が今後もKVMや他のハイパーバイザから発掘され得ることを示唆します。

Hyunwoo Kim氏による一連のLinuxカーネル脆弱性研究

Januscapeは、Kim氏がここ2か月に相次いで公表した3件の重大なLinuxカーネル脆弱性の3件目に位置します。5月にはDirty Frag(CVE-2026-43284、CVE-2026-43500)を公表し、page-cache書き込み経路の脆弱性チェーンを利用して主要ディストロで決定論的にroot権限を取得できる手法を、Dirty Pipe、Copy Failに続く同系統として提示しました。6月にはITScape(CVE-2026-46316)として、KVM/arm64のvGIC-ITS実装内の`vgic_its_invalidate_cache()`におけるrace conditionとdouble-put UAFを悪用した、公開ベースでは最初のKVM/arm64ゲスト脱出を実演しました。

そして今回のJanuscapeがKVM/x86側のゲスト脱出として公表され、Kim氏は自身の説明で「Intel/AMD両方でトリガー可能な最初の一般公開exploit研究」と位置付けています。これら3件は独立したバグ群ではありますが、いずれもLinuxカーネルの深部にある古典的サブシステム(page cache、vGIC-ITS、Shadow MMU)を対象にしており、Kim氏のワークフローとしてはこれらの経年劣化した経路を系統的に洗い直す方向性が明確です。同氏の一連の公表は、単発の派手なexploitではなく、Linuxカーネル基盤に対する構造的な監査キャンペーンの様相を帯びています。

修正確認と実務対応

Januscapeへの対応は、まず修正コミット`81ccda30b4e8`が自組織のカーネルに反映されているかを確認することから始まります。ディストロ側は独自のバージョン番号でバックポートを配布するため、`uname -r`で表示される数値だけで判断することはできず、パッケージの変更履歴(changelog)またはコミットIDの取り込み状況をもって確認する必要があります。Kim氏および複数の分析ソースが強調する運用上のポイントを整理すると、次の通りです。

修正安定版への更新:2026年7月4日にリリースされた各系列の安定版(7.1.3、6.18.38、6.12.95、6.6.144、6.1.177、5.15.211、5.10.260)を適用し、可能な限り上位系列に寄せます。Long-term supportカーネルを使う組織でも複数系列で修正が用意されているため、EOL寸前の系列に張り付いている環境以外は対応可能な状態にあります。
バックポート確認方法:ディストロ提供カーネルの変更履歴またはSRPM/DEBのソース内でcommit ID 81ccda30b4e8への言及を検索します。バージョン番号だけでの判断は避けます。AlmaLinuxは既にテストリポジトリで8/9/10系向けのバックポート提供を開始しています。
暫定回避策:直ちにパッチ適用ができない場合は、`kvm_intel.nested=0`または`kvm_amd.nested=0`をカーネルコマンドラインに追加してネスト仮想化を無効化することで、攻撃面を除去できます。パフォーマンス上の副作用は限定的ですが、ネスト仮想化を業務で利用している環境ではワークロード側との調整が必要です。
公開マルチテナント環境の優先度:非信頼ゲストを受け入れる環境(パブリッククラウド、共同利用ホスティング、CIランナーホストなど)は最優先で対応します。同一物理ホスト上の全テナントVMがホスト全体の停止に巻き込まれるDoSリスクが単一の悪意インスタンスから成立するため、ビジネス影響が大きくなります。
ARM64ホストの別途対応:Januscape単体はx86のみに影響しますが、ARM64 KVMホストにはITScape(CVE-2026-46316)の対処が別途必要です。Kim氏本人がFAQで注意喚起しており、両者を混同せずそれぞれのパッチ状況を確認します。
/dev/kvm権限の見直し:RHEL系のように`/dev/kvm`が0666で提供されるディストロでは、Januscapeが非特権ユーザからのLPEにも転用可能です。仮想化ホスト側では、`/dev/kvm`のアクセスを実際にKVMを利用するプロセスやユーザに限定する運用が推奨されます。

Kim氏が保留している完全版exploitはホストroot権限でのコード実行が可能な水準とされ、これが未公開のまま留まっている点は防御側にとっての時間的な猶予になっていますが、公開されたDoS PoCと同じ根本原因に基づくため、根本対処はいずれにせよ修正コミットの適用に尽きます。同種のShadow MMU起点の脆弱性は今後も追加公表される可能性があり、CVE-2026-46113(2026年5月修正済みの別のShadow paging use-after-free)などが既に存在する状況を踏まえると、KVMのレガシーサブシステム周辺は継続的な監査対象と位置付けるのが実務的です。