Januscape：KVM/x86 环境中的客户机到宿主机逃逸

摘要

本文档描述了由 Hyunwoo Kim (@v4bel) 发现并报告的 Januscape (CVE-2026-53359) 漏洞。这是一个 KVM 逃逸漏洞，可使客户机在 KVM/x86 环境中逃逸至宿主机。据公开所知，这是首个可在 Intel 和 AMD 上触发而不仅限于单一架构的客户机到宿主机利用研究。

Januscape 是 KVM/x86 的 shadow MMU 模拟中的一个释放后使用漏洞。仅通过客户机侧操作即可触发该漏洞，破坏宿主机内核的影子页，并可能威胁那些接受不可信客户机并暴露嵌套虚拟化的 KVM/x86 宿主机，尤其是多租户 x86 公有云（GCP、AWS 等）的客户机-宿主机隔离。

事实上，Januscape 已在 Google kvmCTF 中被成功用作 0-day 漏洞利用。

详细技术信息请参见此处。

[!NOTE] 在向 [email protected] 报告此漏洞后，约定的禁运期已结束，因此该漏洞利用程序已发布到 oss-security，本 Januscape 文档也已公开。披露时间线请参阅技术细节文档。

PoC 结构

在客户机虚拟机内运行 PoC 可以触发宿主机内核恐慌。也存在一个在受控环境中可用的完整逃逸漏洞利用程序，但目前尚未发布，并计划在非常遥远的将来发布。

在 RHEL 等发行版中，/dev/kvm 是全局可写的（0666），因此非特权用户也可以将此漏洞转化为可靠的 LPE 提权至 root。话虽如此，这样做就像用金子买垃圾，所以我不打算讨论它。

PoC 使用方法

1. 在客户机虚拟机内部，安装头文件并构建模块。

# sudo apt-get install -y build-essential linux-headers-$(uname -r)
# make

2. 在客户机内部加载模块。KVM 持有原始的 VMX/SVM 状态，因此先卸载它。在 Intel 上加载时不带参数，在 AMD 上使用 amd=1。

[Intel]
# sudo rmmod kvm_intel; sudo insmod poc.ko

[AMD]
# sudo rmmod kvm_amd; sudo insmod poc.ko amd=1

3. 竞争开始，并在数秒到数分钟内导致宿主机 KVM 崩溃。

[*] poc step 4/4: race live -- host DoS triggering
...
kernel BUG at arch/x86/kvm/mmu/mmu.c (pte_list_remove)
Comm: qemu-kvm

此 PoC 旨在提供准确信息。请勿在您未经授权测试的系统上使用它。

受影响版本

Januscape (CVE-2026-53359) 涵盖的范围从 2032a93d66fa (2010-08-01) 到 81ccda30b4e8 (2026-06-16)。

换句话说，该漏洞潜伏了大约“16 年”。

常见问题

此漏洞有什么影响？

总共有两种影响：

1. KVM 逃逸：仅通过客户机侧操作，攻击者即可破坏运行其虚拟机的宿主机。例如，攻击者仅在公有云上租用了一个实例，就能使宿主机内核恐慌，从而宕掉同一物理机上的所有其他租户虚拟机（DoS），或在宿主机上以 root 权限运行代码，接管宿主机及其上的所有客户机（RCE）。
2. LPE：在 RHEL 等发行版中，/dev/kvm 是全局可写的（0666），因此非特权用户也可以将此漏洞用作可靠的 LPE 来获取 root 权限。

我应该担心吗？

如果您运行一个接受多租户客户机并支持嵌套虚拟化的 x86 KVM 宿主机，或者在其上使用实例，请检查宿主机内核是否已应用 81ccda30b4e8 补丁。

基于 arm64 的 KVM 宿主机是否也存在漏洞？

否。该漏洞仅在 Intel 和 AMD 架构上触发。话虽如此，如果您尚未修补先前发布的 ITScape (CVE-2026-46316)，那么您的 arm64 宿主机也存在漏洞，请及时应用补丁。

此漏洞是否发生在 QEMU 中？

否。与常见发布的 QEMU 逃逸漏洞不同，Januscape 发生在内核级 KVM 中，因此它与 QEMU 的模拟无关。因此，它也可能威胁那些实现并使用自有虚拟化栈的大型公有云。

我需要在客户机虚拟机内拥有 root 权限吗？

是的。插入模块需要客户机内核权限。当您在公有云上获得一个实例时，您通常拥有自己虚拟机的 root 权限，因此满足条件。在没有客户机 root 权限的场景中，必须与诸如 Dirty Frag 之类的 LPE 漏洞链式使用。