#云计算 OVH 发布报告披露如何修复数万台宿主机和数百万台虚拟机的 KVM 漏洞，漏洞危害太高以至于 OVH 决定不提前通知客户直接操作升级。毫无疑问这种内核升级需要重启宿主机会导致客户业务中断，即便如此 OVH 也认为安全性最重要，不可能协调所有客户进行维护。在实际升级过程中也出现多种问题，例如硬件上的内存故障、BIOS 问题、网卡问题、电源问题等等，这些都靠现场工程师立即拆机修复。查看全文：https://ourl.co/114007
欧洲云计算公司 OVH 日前发布复盘文章介绍该公司如何在不到 10 天内修复数万台服务器和数百万台虚拟机存在的 KVM 虚拟化漏洞，这次修复有个重点值得关注的做法：OVH 并未提前通知所有客户，该公司认为与所有客户协调升级时间是不现实的，所以 OVH 支持团队直接部署升级，这导致诸多虚拟机出现中断。
KVM 漏洞对 OVH 以及云计算厂商来说影响非常重大：
CVE-2026-53359 是影响 Linux Kernel x86 KVM 虚拟化子系统的安全漏洞，该漏洞属于释放后使用，攻击者可以在虚拟机内触发宿主机 (母鸡) 崩溃，在更严重的情况下，黑客甚至可以穿透虚拟机直接获得母鸡的管理员权限，因此这个漏洞对云计算厂商来说影响非常重大。
OVH 托管的大量 VPS 服务器和公有云实例都运行在 KVM 虚拟化架构上，就 OVH 而言，承载这数百万台虚拟机的数万台宿主机需要升级内核修复漏洞，OVH 的内部测试表明，在未修复的宿主机上执行漏洞利用代码，只需要 2 分钟就可以触发宿主机崩溃，因此 OVH 必须立即执行内核升级。
此次漏洞修复工作中存在的争议是，OVH 没有提前通知客户就直接执行会中断业务运行的升级操作。OVH 认为单个 VPS 用户触发漏洞就可能导致承载该 VPS 的物理宿主机崩溃，连带影响这台宿主机上的其他虚拟机，甚至可能出现虚拟化逃逸、获得宿主机控制权、窃取数据等严重情况。
而在公有云场景下，虽然宿主机上运行的实例数量比较少，但这些实例往往承载的是数据库、队列、负载均衡等更加关键的业务组件，所以公有云实例也同样受到严重的安全威胁。
有鉴于此 OVH 最终决定按照自己的计划执行内核升级措施，而不是挨个联系所有客户协商升级时间，不过 OVH 通过单独渠道联系企业级客户告知升级时间，至于大量 VPS 用户除非登录控制台否则不会看到升级通知，因为群发邮件数量太大可能会导致工单系统爆炸，所以 OVH 也没有群发邮件通知。
数万台宿主机要升级重启肯定会出现意外情况，尤其是这些物理服务器可能会因为硬件问题出现中断，在实际升级过程中 OVH 遇到诸多问题，例如部分虚拟机在宿主机重启后没有自动恢复、部分同步服务数据损坏、宿主机无法正常重启 (必须将 CMOS 电池拆掉释放电量后再装回去)。
所以 OVH 各地的支持团队都严阵以待，待在机房里的工程师需要随时响应虚拟机无法恢复的情况，如果是软件问题 (部分服务死锁导致无法恢复) 需要立即联机进行干预，如果是硬件问题则需要定位对应的宿主机并拆下来排查，例如在第一波升级中 6000 台宿主机有 20~30 台无法自行恢复，现场工程师就地拆机处理内存、BIOS、网卡以及电源问题等等。
虽然导致客户业务中断但 OVH 认为这是有必要的：
OVH 始终认为所有客户的业务稳定和数据安全是最重要的事情，所以即便在升级前 OVH 已经预料到可能会出现意外问题导致客户业务出现长时间中断，OVH 仍然决定推进升级，OVH 觉得在漏洞风险面前，逐台等待客户确认维护窗口并不现实，迟一秒修复漏洞带来的风险都在增加。
这次事件其实也说明，云计算厂商在处理关键漏洞时，必须在安全风险、客户可用性、热迁移能力、硬件故障率和通知机制等因素之间做取舍，如果单纯为客户可用性而延迟升级，就有可能造成更大的安全风险。
对普通云服务用户而言，能做的事情主要就是保障业务具备基本冗余特性，不要将关键服务放在单台实例上，至少出现服务器中断时还可以通过冗余服务器继续为下游用户提供服务。