Linux 内核 Vghost 漏洞 CVE-2026-74580：本地用户直拿宿主机 root，自建虚拟化环境如何排查与修复

事件概述：一个被命名 Vghost 的内核缺陷

2026 年 10 月 12 日，腾讯朱雀实验室公开了一个名为 Vghost 的 Linux 内核漏洞（编号 CVE-2026-74580）的完整技术细节与演示。问题出在 Linux 内核的 vhost 子系统——这套机制本用来给虚拟机和容器加速网络与 I/O，如今却成了一道可以直接从"虚拟机里的客人"通往"宿主机 root"的门。

按照公开信息，漏洞核心在于：一个能够打开 vhost 设备节点（通常是 /dev/vhost-net 或 /dev/vhost-vsock）的本地用户，可以获得对内核内存的稳定读写能力，绕过 KASLR，并进一步提升为 root。整个过程是确定性的，不需要碰运气、不需要时序竞争。研究还展示了第二条更窄的路径：当虚拟机 virtio 设备位于开启了 iommu_platform 的虚拟 IOMMU 之后、且 vhost 运行在 device-IOTLB 模式时，不受信任的客户机可以让宿主机内核向宿主机上的 QEMU 进程越界写入，导致崩溃或被引导执行。

上游内核的修复补丁其实在 8 月 3 日就已进入稳定树，10 月 12 日跟随完整Write-up一起公开。截至目前，没有公开利用代码，也没有在野利用的报告。

为什么一个 2017 年的小改动会埋下九年隐患

Vghost 最值得玩味的地方，是它的"年龄"。这个缺陷能够存活约九年，源于两次各自都看似合理的改动叠加：2017 年（Linux 4.11）引入的一处缓存捷径，加上 2020 年（Linux 5.9）把地址检查挪到了更晚的执行步骤。单独看每一次改动都没有问题，合在一起就形成了一个地址校验被绕过的窗口。受影响的上游内核范围从 4.11 一直到 7.2-rc4，横跨了绝大多数还在生产环境里跑的内核大版本。

对漏洞评分的分歧也说明了它的性质有多"取决于视角"：内核 CVE 团队给出 8.8 分，Red Hat 7.3、Amazon 7.8、Oracle 7.3，几家的分歧点在于——客户机到宿主机的这次越界写入，究竟算不算跨越了信任边界。对云厂商来说这决定了它是"严重"还是"中危"；对自建虚拟化的运维来说，这个争论没有意义，因为你的宿主机上跑着谁，你比我清楚。

影响范围：谁该今晚就查一遍

先说结论：只要一台机器上同时存在"不受信任的本地用户"和"vhost 设备节点"，就该按高危处理。研究人员在 Ubuntu 26.04、RHEL 9.8、Amazon Linux 2023、Azure Linux 3.0 和 Oracle Linux 10.2 上都复现了"本地用户到 root"的完整利用链。

重点排查对象包括：

• 自建 KVM / QEMU 虚拟化宿主机：尤其是给不同团队、不同客户分配虚拟机的机器，多租户场景下一台宿主机的失守意味着所有租户一起失守。
• 公有云上的自管实例：云厂商托管的 Hypervisor 层由厂商负责，但你在云主机里自己装的 Linux 内核、自己暴露的 vhost 节点，是自己的责任面。
• 共享服务器 / 开发机 / CI Runner：给多人开 shell 账号的机器最危险。在 EL8 到 EL10 上 /dev/kvm 默认全局可写，普通用户甚至可以自己启动一台虚拟机，再从虚拟机里打宿主机。
• 用 Firecracker 等微虚拟机跑多租户沙箱的平台：隔离边界一旦被击穿，同主机上的其他沙箱全部暴露。

修复进度方面，Red Hat、Amazon Linux、Oracle Linux 已发布更新；Ubuntu 修复了 22.04，但 24.04 与 26.04 在 10 月 13 日时仍标注为处理中。上游稳定分支的修复版本包括 5.10.265、5.15.216、6.1.183、6.6.152、6.12.104、6.18.45、7.1.9 和 7.2。注意发行版可能在内核版本号不变的情况下回移补丁，所以判断是否受影响要以发行版自己的 CVE 追踪页为准，不能只看内核版本号。

攻击风险与利用前提

需要把话说完整：这个漏洞不是远程可打的，攻击向量是"本地"。攻击者必须先在一台虚拟机（或宿主机上）取得代码执行权，才能继续。因此它不会像蠕虫那样自己在内网里扩散，公网上的扫描器也没法直接命中它。

但在虚拟化和多租户场景下，"本地"这个词的含义会变形——云厂商存在的意义就是让互不信任的客户代码跑在同一批物理机上，一个客户虚拟机里的"本地攻击者"，对宿主机和其他租户来说就是真正的威胁。再加上利用过程确定性高、不需要时序运气，且已在五个主流发行版上复现，一旦出现公开利用代码，批量利用的门槛并不高。目前无公开 exploit、无在野报告，属于"修复窗口仍然开着"的阶段，这也是现在动手最划算的原因。

排查思路：三条命令先过一遍

排查本身很轻量，不需要装任何工具，三条命令加一次核对：

1. 确认内核版本：执行 uname -r，然后拿这个版本去对照你所用发行版的 CVE-2026-74580 追踪页（Red Hat、Ubuntu、Oracle 等均有独立页面），确认是否已修复；不要只看上游版本号，因为发行版会回移补丁。

2. 检查 vhost 设备节点权限：执行 ls -l /dev/vhost-net /dev/vhost-vsock。研究团队测试的五个镜像中，有四个设备节点是全局可读写的（mode 0666）——这意味着宿主机上任何本地用户都能打开它，也就具备了利用前提。Ubuntu 上将访问限制在了 kvm 组，是更合理的默认值。

3. 确认谁在碰这台机器：列出拥有 shell 账号的用户和运行中的虚拟机清单，特别关注 /dev/kvm 是否全局可写、是否有用户能自启虚拟机。如果一台机器的本地用户里有你不完全信任的人，上面两条即使暂时安全，也应视为高风险。

修复与缓解建议

根本修复只有一个：升级到发行版提供的、包含修复的内核，然后重启宿主机让新内核生效。客户机到宿主机的逃逸路径没有任何临时替代方案，只有打了补丁的内核能真正堵住。升级与重启涉及生产环境，请按保守节奏来：先在测试环境验证内核与业务兼容性，确认虚拟机和容器在新内核下正常启动，再排维护窗口升级；升级前备份宿主机关键配置、虚拟机镜像和业务数据，评估重启对在线业务的影响，并提前通知受影响的租户或团队。

如果短期内有延迟打补丁的理由（例如厂商尚未发布对应内核），可以做以下缓解措施降低暴露面：

• 收紧 vhost 设备节点权限：移除 /dev/vhost-net、/dev/vhost-vsock 的全局访问权限，仅将属组限定给确实需要它的虚拟化服务账号，例如 chgrp kvm /dev/vhost-net /dev/vhost-vsock 后按最小必要原则授权，并同步 udev 规则保证重启后仍生效。
• 管理能自启虚拟机的用户：对存在不可信本地用户的宿主机，按需禁用非特权用户命名空间等可被用于放大攻击面的内核特性；这一改动影响面较大，建议先在测试环境评估业务依赖。
• 网络侧减害：对暂时无法关闭的客户机接口，评估关闭校验和 offload 的可行性（virtio-net 显式设置 csum=off），以牺牲一定吞吐换取攻击面收敛；可通过 virsh dumpxml <虚拟机名> | grep 'csum=' 查看客户机是否显式设置过相关属性，未设置时遵循 QEMU 默认值（默认开启 offload）。
• 云主机用户同步自查：在 VPS 里更新自己的内核属于良好卫生习惯，但请理解——客户机内核更新并不能修复宿主机的洞。如果你的服务商没有发布公告，开工单询问宿主机修补计划和重启时间。

以上命令和步骤均建议结合发行版官方公告执行，以厂商安全通告为最终依据。

后续观察

接下来一段时间值得盯住的信号有三个：一是 Ubuntu 24.04 / 26.04 等仍在"处理中"的发行版何时发布修复内核；二是是否出现公开利用代码或首个在野利用报告——目前两者都没有，一旦出现，暴露在共享宿主机上的业务应立刻按事件响应流程处理；三是上游补丁是否会有后续修订（社区已提示存在跟进修复的可能），自编译内核的团队需要关注稳定树的更新。

Vghost 与今年早些年的 Januscape、Zapscape 等 KVM 逃逸问题一样，再次说明虚拟化隔离的边界从来不是理所当然的。对自建虚拟化环境的团队来说，最实际的动作不是恐慌，而是把上面那三条排查命令跑一遍——先搞清楚自己有没有暴露，再决定要不要今晚就打补丁。