Januscape：ゲストVMのホストへのエスケープを可能にする16年前のKVMの脆弱性

テナント間の壁に亀裂が入った

クラウドコンピューティングの前提全体は、ある静かな仮定に基づいています。それは、レンタルした仮想マシンが、それが動作している物理ホストにアクセスすることはできず、隣にある第三者のVMにアクセスすることも絶対にできないということです。その壁はハイパーバイザーの分離と呼ばれ、Linuxでは世界のクラウドサーバーの非常に大きな割合を動かしているKernel-based Virtual MachineであるKVMによって強制されています。

2026年7月4日、Linuxカーネルのメンテナは、16年間にわたりその壁を密かに蝕んでいた脆弱性を修正するため、一連の緊急安定版リリースを出荷しました。CVE-2026-53359として追跡され、「Januscape」と名付けられたこの脆弱性は、通常のゲストVM内で実行されているコードがIntelとAMDの両方のシステムでホストカーネルを破損させることを可能にします。パッチの適用により詳細が公開されたため、これが今重要となります。公開された修正がある場所には、すぐに公開のエクスプロイトが登場します。

Januscapeとは一体何なのか

JanuscapeはUse-After-Freeの脆弱性です。平たく言えば、Use-After-Freeは、メモリ領域が既に返却され他の目的で再利用された後も、プログラムがその領域を使い続けるときに発生します。これは、住人が退去して見知らぬ人が引っ越してきた後の住所に手紙を郵送するようなものです。攻撃者がその「解放された」場所にシステムに書き込ませることができたものは何であれ、それが依然として元の信頼されたデータであるかのように扱われてしまいます。

このバグはKVMのシャドウMMUに存在します。ゲストVMが実行されるとき、独自のメモリアドレス概念を持ちますが、それらはホストの実際の操作用アドレスではありません。両者の間で変換を行う必要があり、それがメモリ管理ユニットです。多くの構成で、KVMはゲストのテーブルをホストの実テーブルにミラーリングする「シャドウ」ページテーブルを使用して、この変換をソフトウェアで処理します。JanuscapeはそのシャドウMMUエミュレーションの欠陥です。ゲスト側の操作だけで、攻撃者はホストカーネルのシャドウページ（ゲストを閉じ込めておくための構造そのもの）を破損させることができます。

なぜ「IntelとAMDの両方」が恐ろしい部分なのか

ほとんどの仮想マシンエスケープバグはベンダー固有のものです。これらはIntelのVT-xまたはAMDのAMD-Vの癖を悪用するため、一方のチップを実行するプロバイダーが危険にさらされている間、もう一方は安全です。Januscapeは異なります。これはKVMが両方のベンダー間で共有するシャドウMMUコード内に位置するため、IntelとAMDの両方のx86システムでトリガー可能であることが公に知られている最初のゲストからホストへのエスケープとして説明されています。

混在したハードウェアを持つクラウド事業者にとって、これは通常の避難経路をなくしてしまいます。フリートを移行するための「安全な」プロセッサは存在しません。この単一の手法は、脆弱なコードが実行されるあらゆる場所で機能します。

実際のところ、どれほど深刻なのか

公表された概念実証（PoC）は、「おとなしい」バージョンの損害を与えます。つまりホストをパニックさせます。これは無害ではありません。パニックは物理マシン全体とその上で動作しているすべてのテナントVMをクラッシュさせ、その筐体上の全員に対するサービス拒否を引き起こします。

より深刻なのは、公表されていない部分です。このバグを発見して報告したセキュリティ研究者のHyunwoo Kim氏（@v4bel）は、公開されていない別のエクスプロイトにより、同じ脆弱性が完全なホストコード実行に繋がると述べています。これは悪夢のようなシナリオです。1つの安価なVMからの攻撃者コードがホストとして実行され、隣接するすべてのテナントのマシンを読み取り・書き換えできるようになります。このバグは、まさにこのクラスの完全なゲストからホストへのエスケープに対して最大25万米ドルを支払う管理された報酬プログラムであるGoogleのkvmCTFにゼロデイとして提出されるほど深刻でした。そして、それはおよそ16年間にわたり見落とされ続けていました。

実際に誰がリスクにさらされているのか

これがアクティブな脅威となるには、2つの条件を満たす必要があります。

信頼できないゲストを受け入れている場合。 パブリッククラウド、VPSプロバイダー、共有CI/CDランナー、サンドボックスサービスなど、第三者があなたが運用するハードウェア上でVMを起動できる場所すべてが該当します。

ネストされた仮想化を有効にしている場合。 攻撃経路は、それらのゲストに対してネストされた仮想化が有効になっていることに依存しています。

自身のワークロードのみをホストするシングルテナントサーバーを実行している場合、リスクははるかに低くなります。攻撃者は既に自身のVMの1つの内部に入り込んでいる必要があるためです。しかし、計算資源を販売または共有している場合は、これを緊急課題として取り扱ってください。

ステップ1：影響を受けているか確認する

実行中のカーネルバージョンおよびネストされた仮想化が有効になっているかを確認します。

# Which kernel am I running?
uname -r

# Is nested virtualization on? (Intel host)
cat /sys/module/kvm_intel/parameters/nested

# Or on an AMD host
cat /sys/module/kvm_amd/parameters/nested

どちらかのコマンドが以下を返す場合 Y （または 1）であり、カーネルが以下の修正リリースより古い場合、対象範囲となります。

ステップ2：修正されたカーネルにパッチを適用する

修正された安定版カーネルは2026年7月4日に出荷されました。以下のバージョンのいずれか以上に更新し、再起動して適用してください。

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

ほとんどのディストリビューションでは、これは通常のパッケージ更新です。

sudo apt update && sudo apt full-upgrade   # Debian / Ubuntu
sudo dnf update kernel                       # Fedora / RHEL family
# then reboot into the new kernel
sudo reboot

再起動後、以下で確認します uname -r ：パッチ適用済みのビルドで動作していることを確認してください。

ステップ3：すぐにパッチを適用できない場合は、ネストされた仮想化を無効化する

信頼できないゲストを受け入れているものの、すぐに再起動できないホストの場合、ネストされた仮想化を無効化することで攻撃経路が排除されます。

# Intel host
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

# AMD host
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

反映させるためにモジュールをリロード（または再起動）します。トレードオフを理解してください。これにより、テナントが依存している正当なネストされた仮想化（VM内で動作するVM）が機能しなくなります。これは応急処置であり、カーネルパッチの代わりにはなりません。

結論

Januscapeは、クラウドコンピューティングにおける最も強固な壁も依然としてソフトウェアでできており、16年前に書かれたソフトウェアでも1つのミスを長期間潜ませて業界全体を脅かす可能性があることを思い出させます。朗報なのは、修正プログラムが既にリリースされており、軽減策もシンプルであることです。計算資源を共有するすべての事業者の前にあるタスクは地味ですが明確です。カーネルを確認し、パッチを適用し、本日パッチを適用できない場合は可能になるまでネストされた仮想化をオフにしてください。公開パッチと公開の兵器化されたエクスプロイトの間の猶予期間は、月単位ではなく日単位で計測されます。

メリット

• 修正プログラムが既に存在する。 脆弱性が公表されたのと同じ日にパッチ適用済みの安定版カーネルがリリースされたため、修復作業は研究プロジェクトではなく日常のルーチンアップデートです。
• 明確で即効性のある軽減策。 ネストされた仮想化を無効化することで、新しいカーネルに再起動する前であっても攻撃経路を遮断できます。
• 責任ある開示が機能した。 バグはGoogleのkvmCTF報酬プログラムを通じてメンテナに到達し、兵器化されたエクスプロイトが登場する前にパッチが出荷されました。

デメリット

• 16年間にわたる無防備な露出。 開示前にこの脆弱性が密かに悪用されなかったと確信を持って言える人はいません。
• マルチベンダーに及ぶ影響範囲。 共有されたシャドウMMUコード内に存在するため、フォールバックできる「安全な」IntelまたはAMDのチップは存在しません。
• 完全なRCEエクスプロイトが非公開で存在する。 公開されたPoCはホストをクラッシュさせるだけですが、研究者は非公開のより強力なバージョンがホストでのコード実行を達成することを確認しています。

注意

公開された概念実証をリスクの上限として扱わないでください。それはホストをパニックさせるだけです。本当の危険は、完全なホスト実行を取得すると報告されている非公開のエクスプロイトです。マルチテナントインフラを運用している場合は、利便性よりもカーネルパッチの適用を優先し、以下で検証してください uname -r ：すべてのホストが実際に修正されたビルドに再起動したことを確認してください。古いカーネルをまだ実行しているパッチ適用済みパッケージは何の保護も提供しません。

よくある質問

これは個人のラップトップやデスクトップに影響しますか？ 間接的な影響のみです。ネストされた仮想化を使用して信頼できないゲストVMを実行していない場合、この攻撃の対象ではありませんが、カーネルにパッチを適用することは依然として優れたセキュリティ対策です。

ネストされた仮想化を無効化するだけで十分ですか？ 信頼できないゲストに対する既知の攻撃経路は削除されますが、これは応急処置です。できるだけ早くカーネルパッチを適用し、パッチが適用されたホストでのみネストされた仮想化を再有効化してください。

クラウドプロバイダーがこれを代わりに修正してくれますか？ 主要なプロバイダーは自社側でホストハイパーバイザーにパッチを適用します。お客様ご自身のゲストVMは脆弱なコンポーネントではありません。もしあなたが プロバイダーである場合 — 計算資源の再販売や共有ランナーの運用を行っている場合 — 責任はあなたにあります。

なぜ「Januscape」と呼ばれているのですか？ この名前は、ローマ神話の2つの顔を持つ神ヤヌス（Janus）を想起させます。これはx86世界におけるIntelとAMDという両方の側面（顔）に跨がる脆弱性にふさわしいものです。

タグ

security, linux, virtualization, kvm, cve