潜伏16年的KVM逃逸漏洞Januscape:首个Intel与AMD双架构通用攻击

2026年7月6日,安全研究员Hyunwoo Kim在oss-security邮件列表公开了代号"Januscape"的KVM逃逸漏洞。这个编号为CVE-2026-53359的缺陷自2010年8月1日引入Linux内核,直到2026年6月19日才被修复——它在云计算基础设施的心脏位置潜伏了整整16年。

打破Intel与AMD的边界

Januscape最不寻常的特征是它的通用性。Kim在技术文档中声称,这是"首个公开的可同时在Intel和AMD上触发的guest-to-host逃逸漏洞"。在虚拟化安全领域,针对特定硬件平台的漏洞是常态:Intel的EPT和AMD的NPT虽然功能相似,但实现细节差异巨大,能够跨越两个阵营的攻击向量极为罕见。

漏洞藏在KVM影子MMU的kvm_mmu_get_child_sp()函数中。KVM为每个虚拟机维护一套私有的影子页表,用于将客户机的内存视图映射到物理内存。这个函数在重用现有影子页时,只检查GFN(客户机帧号)是否匹配,完全忽略了页表的role属性——是直接映射的叶节点,还是指向下级页表的间接节点。

这个看似无害的疏漏制造了一个use-after-free陷阱。攻击者可以构造嵌套页表,让同一个物理页既作为2MB大页的叶节点,又作为页表本身。当在huge映射和table映射之间快速切换时,直接分裂的影子页会被错误复用为间接页,生命周期记账失败,留下孤儿父指针。一旦该页被释放,其backing内存可被占用,形成可利用的UAF原语。

受影响的版本从Linux 2.6.36覆盖到7.1.2,几乎包含了过去16年发布的所有内核。KVM代码库经历了数百名开发者的维护和多轮安全审计,这个位于关键路径上的缺陷却始终未被察觉。

Google kvmCTF的第一份战利品

Januscape不是实验室产物。Kim将它作为0-day提交给了Google的kvmCTF计划——这是一个在2024年6月27日正式启动的漏洞赏金项目,为完整的虚拟机逃逸提供最高25万美元的奖励。参赛者预约时间段访问Google Bare Metal Solution环境中的guest虚拟机,如果能突破隔离获取主机上的flag,就能证明漏洞的实战价值。

Kim公开的PoC可以让客户机内的内核模块触发主机panic。技术文档显示,当被重用的影子页的leaf GFN偏离预期时,pte_list_remove()的完整性检查会在反向映射表中找不到对应条目,触发KVM_BUG_ON_DATA_CORRUPTION断言,导致整个主机内核崩溃。

但这只是DoS路径。Kim表示另有一个完整利用版本可以在主机上执行代码,但"计划在非常遥远的未来"才会公开。通过精心选择victim对象,UAF原语可以实现向攻击者控制的偏移写入固定常量0x8000000000000000,这足以劫持主机内核的控制流。

Google是否为Januscape支付了奖金,以及具体金额是多少,Kim的披露文档和公开报道均未提及。kvmCTF的规则如何影响披露时间线也是未解之谜。

公有云的双重威胁路径

对于运行x86 KVM的多租户公有云,Januscape构成直接威胁。攻击前提有两个:主机启用了嵌套虚拟化,攻击者在客户机内拥有root权限。前者在GCP、AWS等云平台上并非默认配置,但许多实例类型会提供该功能以支持容器或二级虚拟化需求;后者对于租用实例的用户来说是标配权限。

一旦条件满足,租用单个实例的攻击者可以让承载该虚拟机的物理服务器崩溃,导致同一台机器上所有其他租户的虚拟机下线。更严重的是,完整利用可以让攻击者在主机上获得root权限,进而接管该物理机上的所有客户机——包括读取其他租户的内存、劫持网络流量、植入后门。

在另一个影响路径上,RHEL等发行版将/dev/kvm的权限设置为0666,意味着任何本地用户都可以打开KVM设备。这让Januscape可以被用作本地提权漏洞,让非特权用户获得root。不过Kim对此不以为然,称"这等于用金子换垃圾"——相比价值25万美元的虚拟机逃逸,本地提权的利用价值微不足道。

一行代码修复16年缺陷

披露时间线显示了一次高效的协调过程。6月12日Kim向security@kernel.org报告漏洞,5天后测试补丁发布,6月19日修复合并进主线内核。补丁的核心修改只有一行:在kvm_mmu_get_child_sp()的重用条件中增加spte_to_child_sp(*sptep)->role.word == role.word检查,确保影子页不仅GFN匹配,role属性也必须一致。

完整修复需要两个补丁。除了CVE-2026-53359本身的commit 81ccda30b4e8,还必须应用CVE-2026-46113的配套修复commit 0cb2af2ea66a,后者解决了frame-number的相关问题。7月4日,CVE编号正式分配,稳定版内核7.1.3、6.18.38、6.12.95、6.6.144、6.1.177、5.15.211、5.10.260同步发布修复。两天后,与linux-distros邮件列表协商的禁公期结束,Kim在oss-security公开了完整技术细节。

发行版的响应速度不一。Debian的testing和unstable分支已完成修复,SUSE的多数Enterprise产品仍处于pending状态,Red Hat及其衍生版本在追踪中。但AWS、GCP、Azure等主流公有云厂商没有发布官方声明,也未公开补丁部署时间线或客户通知措施。

对于无法立即升级的系统,临时缓解方案是禁用嵌套虚拟化。在启动参数中加入kvm_intel.nested=0(Intel)或kvm_amd.nested=0(AMD)可以阻断攻击路径,代价是失去在虚拟机内运行虚拟化工作负载的能力。

两个月内的三记重拳

Januscape是Kim在2026年披露的第三个重大Linux内核漏洞。5月7日,他公开了Dirty Frag(CVE-2026-43284和CVE-2026-43500),这是一个page-cache写漏洞链,可以在Ubuntu、Debian、Fedora等主流发行版上确定性获取root权限。该漏洞延续了Dirty Pipe和DirtyCred开创的漏洞类别,且因另一方破坏协调禁公期而提前披露,在各发行版发布补丁前就有了公开的PoC。

6月,ITScape(CVE-2026-46316)打破了另一个边界——这是首个公开的KVM/arm64 guest-to-host逃逸漏洞,利用vGIC-ITS(虚拟通用中断控制器的中断转换服务)中的竞态条件。CVSS评分9.3分的严重级别漏洞让arm64架构的公有云同样面临虚拟化隔离被突破的风险。

三个漏洞的影响模式形成互补。Dirty Frag横向覆盖多个发行版,但限于本地提权;ITScape纵向突破虚拟化隔离,但只针对arm64;Januscape则是纵向加横向,既突破虚拟化隔离,又覆盖Intel和AMD双架构,且潜伏时间长达16年。

Kim是谁,在哪个机构工作,使用什么方法论在两个月内发现三个重大漏洞,这些问题没有答案。他的GitHub账号@v4bel只留下了PoC代码和技术文档,没有个人博客或采访记录。这三个漏洞之间是否存在技术关联,是同一研究线索的副产品,还是独立发现的成果,外界无从得知。