Hacker News 中文摘要

RSS订阅

Januscape: KVM/x86中的访客到宿主机逃逸 [CVE-2026-53359] -- Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

原文链接 | HN讨论 | 2026-07-07 16:15:18

文章摘要

Januscape（CVE-2026-53359）是KVM/x86中的一个漏洞，利用影子MMU模拟中的释放后重用缺陷，允许虚拟机逃逸到宿主机。这是首个同时影响Intel和AMD架构的逃逸漏洞，威胁多租户x86云平台的安全性。

文章总结

Januscape：KVM/x86 虚拟机逃逸漏洞

摘要

本文档描述了由 Hyunwoo Kim（@v4bel）发现并报告的 Januscape（CVE-2026-53359） 漏洞。这是一个 KVM 逃逸漏洞，允许虚拟机在 KVM/x86 环境中从客户机逃逸到宿主机。据公开信息所知，这是首个在 Intel 和 AMD 两种架构上均可触发的客户机到宿主机利用研究，而非局限于单一架构。

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

事实上，Januscape 已作为零日漏洞成功用于 Google kvmCTF 竞赛。

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

注意：向 linux-distros@vs.openwall.org 报告此漏洞后，约定的保密期已结束，因此该利用代码已发布至 oss-security，本文档也已公开。披露时间线详见技术文档。

PoC 结构

在客户机虚拟机内运行 PoC 可触发宿主机内核崩溃。虽然存在可在受控环境中实现完全逃逸的利用代码，但目前尚未发布，计划在遥远的未来发布。

在 RHEL 等发行版上，/dev/kvm 具有全局可写权限（0666），因此非特权用户也可将此漏洞转化为可靠的本地提权至 root。不过，这样做如同用黄金换垃圾，故不赘述。

PoC 使用方法

  1. 在客户机虚拟机内安装头文件并构建模块： ```

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

make

```

  1. 在客户机内加载模块。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

```

  1. 竞争条件开始，数秒至数分钟内宿主机 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 逃逸：仅通过客户机侧操作，攻击者即可攻陷运行其虚拟机的宿主机。例如，在公有云上仅租用一个实例的攻击者，可使宿主内核崩溃，导致同一物理机上的所有其他租户虚拟机宕机（拒绝服务），或在宿主机上以 root 权限执行代码，从而控制宿主机及其所有客户机（远程代码执行）。

  2. 本地提权：在 RHEL 等发行版上，/dev/kvm 具有全局可写权限（0666），因此非特权用户也可将此漏洞用作可靠的本地提权手段获取 root 权限。

我应该担心吗？

如果您运营接受多租户客户机并支持嵌套虚拟化的 x86 KVM 宿主机，或使用基于此类宿主机上的实例，请确保宿主内核已应用 81ccda30b4e8 补丁。

基于 arm64 的 KVM 宿主机是否也受影响？

不受影响。此漏洞仅在 Intel 和 AMD 架构上触发。但如果您尚未修补此前发布的 ITScape（CVE-2026-46316），您的 arm64 宿主机仍存在风险，请及时应用补丁。

此漏洞是否出现在 QEMU 中？

不出现。与常见的 QEMU 逃逸漏洞不同，Januscape 发生在内核态 KVM 中，因此独立于 QEMU 的模拟触发。正因如此，它也能威胁那些实现并使用自有虚拟化栈的大型公有云。

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

需要。插入模块需要客户机内核权限。在公有云上分配实例时，用户通常对自己的虚拟机拥有 root 权限，因此满足此条件。在无客户机 root 权限的场景下，需与 Dirty Frag 等本地提权漏洞配合使用。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 漏洞严重性与影响范围（评分：None，作者：rvz）

    • 该漏洞是首个同时影响AMD和Intel的KVM客户机到宿主机漏洞，自2010年引入，潜伏16年。
    • 关键引用："This is a very nasty vulnerability and risks any service that uses and allows nested x86 virtualization features at risk." / "It was only a matter of time that a vulnerability in KVM would appear. This one is really not good as it is the first KVM guest-to-host exploit working on both AMD and Intel."

  2. 嵌套虚拟化的风险与建议（评分：None，作者：trebligdivad）

    • 嵌套虚拟化增加复杂性，L0层需处理L2层错误，建议公共VM主机禁用嵌套功能。
    • 关键引用："IMHO the extra complexity (and historical flakiness of it) - makes me say that enabling nesting is a bad idea for public VM hosts." / "the L0 top level hypervisor sees faults from the L2 and has to figure out that they are actually L2 not L0."

  3. 资源共享的经济与安全权衡（评分：None，作者：TZubiri）

    • 共享资源降低成本但增加安全风险，建议严肃项目使用专用服务器（200美元/月以上）。
    • 关键引用："If you share resources, that reduces costs, but increases security risks." / "just use a dedicated server, and avoid a whole class of LPE vulnerabilities just to save some $."

  4. 设备文件权限问题（评分：None，作者：codedokode）

    • 质疑Linux中设备文件（如/dev/kvm）为何对非特权用户可写，导致本地提权风险。
    • 关键引用："Why on Linux device files are accessible by untrusted applications?" / "LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root."

  5. 漏洞触发条件（评分：None，作者：br0ceph）

    • 询问是否必须启用嵌套虚拟化才受影响，禁用该功能是否免疫。
    • 关键引用："does this mean that you must have nested virtualization enabled to be vulnerable." / "does disabling this feature in the host os or bios, make you immune to this bug?"

平衡性总结： - 多数评论强调漏洞的严重性，尤其是对多租户VM服务的影响。 - 部分评论建议禁用嵌套虚拟化或使用专用服务器作为缓解措施。 - 也有评论关注底层权限配置问题（如设备文件权限），认为这是漏洞利用的辅助因素。