Januscape：潜伏 16 年的 KVM 漏洞，可导致虚拟机客体逃逸至宿主机

租户之间的隔墙刚刚破裂

云计算的全部承诺都建立在一个隐性假设之上：你租用的虚拟机无法触及它运行的物理宿主机，更无法触及相邻的其他陌生人的虚拟机。这道屏障被称为虚拟机监控程序隔离（hypervisor isolation）。在 Linux 上，它由 KVM（基于内核的虚拟机）来强制执行——全球大部分云服务器都由 KVM 提供动力支撑。

2026 年 7 月 4 日，Linux 内核维护者发布了一波紧急稳定版本，以修复一个默默破坏这道防线长达 16 年的漏洞。该漏洞的编号为 CVE-2026-53359，代号“Januscape”，它允许在普通客体虚拟机内运行的代码损坏宿主机内核——无论是在 Intel 还是 AMD 系统上。这一点之所以在现在至关重要，是因为补丁的发布意味着技术细节已经公开，而一旦有了公开的修复方案，公开的利用程序（exploit）很快就会随之而来。

Januscape 到底是什么

Januscape 是一个释放后重用（use-after-free）漏洞。通俗地说，当程序在某块内存已经被归还并挪作他用之后，依然继续使用这块内存时，就会发生释放后重用——就像在租客搬走、陌生人搬入之后，仍然把信寄到原地址一样。攻击者诱骗系统写入那个“已释放”位置的任何内容，都会被当作原本可信的数据来处理。

该漏洞存在于 KVM 的 shadow MMU 中。当客体虚拟机运行时，它拥有自己的内存地址概念，但这些并不是宿主机的真实地址。必须有东西在两者之间进行转换，这个东西就是内存管理单元（MMU）。在许多配置中，KVM 通过软件使用“影子（shadow）”页表来进行这种转换，将客体页表映射到宿主机的真实页表中。Januscape 就是这种 shadow-MMU 仿真机制中的缺陷：仅凭客体端的行为，攻击者就能损坏宿主机内核的影子页——而这正是用来限制客体虚拟机的关键结构。

为什么“Intel 和 AMD 双双中招”令人担忧

大多数虚拟机逃逸漏洞都针对特定芯片厂商。它们利用的是 Intel VT-x 或 AMD AMD-V 的特定机制，因此使用某一厂商芯片的提供商受到威胁，而使用另一厂商的则是安全的。Januscape 则不同。它位于 KVM 在两个厂商之间共享的 shadow-MMU 代码中，这就是为什么它被描述为首个已知能在 Intel 和 AMD x86 系统上同时触发的公开客体到宿主机逃逸漏洞。

对于拥有混合硬件架构的云服务运营商来说，这堵死了通常的避险途径。没有“安全”的处理器可供迁移服务器集群。只要运行了受影响的代码，这一攻击手法在所有平台上都能生效。

实际危害有多严重

公开发布的概念验证程序（PoC）造成的是较“温和”的破坏：导致宿主机崩溃（panic）。这绝非无害——内核 panic 会使整台物理机及其上运行的所有租户虚拟机瞬间崩溃，从而造成针对该机器上所有用户的拒绝服务（DoS）。

更糟糕的是尚未公开的部分。发现并报告该漏洞的安全研究员 Hyunwoo Kim（@v4bel）表示，另一个未发布的利用程序可以将同一漏洞转化为完全的宿主机代码执行（host code execution）。这是最可怕的噩梦情景：攻击者在一台廉价虚拟机中运行的代码可以获得宿主机权限，从而能够读取并改写相邻所有租户的虚拟机。该漏洞非常严重，以至于被作为零日漏洞提交给 Google 的 kvmCTF——这是一个受控悬赏项目，专门为此类完全的客体到宿主机逃逸支付最高达 250,000 美元的奖金。而它就这样在眼皮底下潜伏了大约 16 年。

究竟谁面临风险

要使该漏洞对你构成现实威胁，必须同时满足以下两个条件：

你接收不可信的客体虚拟机。 公有云、VPS 提供商、共享 CI/CD runner、沙箱服务——即任何陌生人可以在你运行的硬件上创建虚拟机的场景。

你开启了嵌套虚拟化（nested virtualization）。 攻击路径依赖于为这些客体虚拟机启用了嵌套虚拟化。

如果你运行的是仅托管自身工作负载的单租户服务器，暴露风险要低得多——攻击者首先需要打入你自己的虚拟机内部。但如果你对外销售或共享算力，请将此视为紧急事项处理。

步骤 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

在大多数 Linux 发行版中，这只是常规的软件包更新：

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

重新加载模块（或重启）以使其生效。请注意权衡代价：这会中断你租户所依赖的任何合法嵌套虚拟化功能（即在虚拟机中运行虚拟机）。这是一种权宜之计，不能替代内核补丁。

结论

Januscape 再次提醒我们，云计算中最坚固的防线依然是由软件构建的，而十六年前编写的软件可能会隐匿单个错误长达数年，进而威胁整个行业。好消息是，修复程序已经发布，缓解措施也很简单。每位算力共享运营商面前的任务虽然平凡但很明确：检查内核，打上补丁；如果今天无法打补丁，就关闭嵌套虚拟化，直到能够修复为止。从公开补丁到出现公开武器化的利用程序，窗口期是以天计算的，而不是以月计算。

有利因素

• 修复方案已经存在。 已打补丁的稳定内核在漏洞公开的当天就已发布，因此修复只是一项例行更新，而不是研究项目。
• 干脆利落的即时缓解措施。 禁用嵌套虚拟化甚至在你重启进入新内核之前就能封堵攻击路径。
• 协调漏洞披露机制发挥了作用。 漏洞通过 Google 的 kvmCTF 悬赏项目送达维护者手中，且补丁赶在武器化利用程序出现前就已发布。

不利因素

• 长达 16 年的默默暴露。 没人能确定该漏洞在披露之前是否从未被秘密利用过。
• 跨厂商影响范围。 由于漏洞位于共享的 shadow-MMU 代码中，没有可以退守的“安全”Intel 或 AMD 芯片。
• 私下存在完整的 RCE 利用程序。 公开的 PoC 只能崩溃宿主机，但研究人员证实，更强大、未发布的版本可以实现宿主机代码执行。

注意事项

切勿将公开的概念验证程序视为风险上限。它只是让宿主机 panic；真正的危险据报道是能获得完全宿主机执行权限的未公开利用程序。如果你运营多租户基础设施，请将内核补丁置于便利性之上，并通过 uname -r 验证每台宿主机实际上都已经重启并运行已修复的构建——打上了补丁的软件包如果依然运行着旧内核，起不到任何防护作用。

常见问题

这会影响我的个人笔记本或台式机吗？ 仅间接相关。如果你没有使用嵌套虚拟化运行不可信的客体虚拟机，你并不是这种攻击的目标群体——但更新内核仍是良好的卫生习惯。

仅禁用嵌套虚拟化就足够了吗？ 它消除了不可信客体的已知攻击路径，但属于权宜之计。请尽快应用内核补丁，并仅在已打补丁的宿主机上重新启用嵌套虚拟化。

我的云服务提供商能帮我修复这个问题吗？ 主流提供商会在其侧对宿主机 hypervisor 打补丁；你自己的客体虚拟机并不是受漏洞影响的组件。如果你 属于 提供商本身——转售算力或运行共享 runner——责任就在于你。

为什么它被称为“Januscape”？ 该名称源于罗马双面神雅努斯（Janus）——非常契合这一横跨 x86 世界中 Intel 和 AMD 两大阵营的漏洞特点。

标签

security, linux, virtualization, kvm, cve