客户开了一台 VPS，某天早上 SSH 连不上，商家后台也没有任何告警，重启之后机器回来了，但数据库的 binlog 少了几个小时。这类“上游先出事”的故障，租户能查的线索少得可怜。10 月 15 日公开的 CVE-2026-99999 就是同一类问题的极端版本：漏洞不在你的 VPS 里，在你 VPS 下面那一层，而你既看不到那一层的版本号，也装不了它的补丁。三个月内第三个 KVM 客人机到宿主机逃逸的公开披露，让“KVM 就等于安全”这个默认假设需要重新算一遍。
先说结论，省得读到一半还在找重点。这个漏洞修的是宿主机内核，不是 VPS 里的内核。你在客人机里跑 apt upgrade 或 yum update，对这个漏洞没有任何作用。你能做的是四件事：确认自己机器的内核确实不在受影响区间（这一项只保证客人机侧没连带风险）、把控制面从“连不上就完蛋”改成可迁移、检查商家是否真的重启过宿主、以及在下单时把这条问题写进问价清单。下面把机制、可核查的版本号、以及每个动作的具体命令拆开。
漏洞到底落在哪一行：校验和卸载把写入位置交给了不可信的一方
要理解为什么租户无能为力，得先看清这层关系。KVM 的虚拟机网卡叫 virtio-net，为了省 CPU，它把计算校验和这件事做成“卸载”：客人机发包时不算校验和，只在包头旁边放一段元数据，告诉宿主机内核“校验和从哪个偏移开始算、结果写到哪个位置”。宿主机收到后调用 skb_checksum_help() 补算并写入。
问题出在这段元数据完全由客人机提供。内核在补算之前没有验证 checksum_start 是否落在合法范围内，于是客人机指定的写入位置可以落在已经通过路由与校验的 IPv4 头里面。官方 CVE 记录的标题就是修复内容本身：ipv4: validate checksum_start before completing checksum，也就是在完成校验和之前先验证起始偏移。
攻防演示里，研究人员把 IPv4 头的 IHL 字段从 20 字节改成了 60 字节，而当时的分片缓冲区只有 28 字节有效数据。随后 ip_do_fragment() 信任这个被改大的长度，ip_frag_next() 越过 skb 的逻辑长度多拷贝 32 字节进发出的报文，宿主内存就这样泄露给了客人机。反复执行同一序列，泄露可以连续发生，再往前一步就是写内存和提权。
CVSS 向量里的那三个字母，说明了影响范围
官方记录的向量是 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H，基础分 9.3，定级 CRITICAL。多数人只看得分，其实关键在 S:C 这一位。S 是 Scope，S:C 表示“范围改变”，意思是这次攻击的影响超出了攻击者原本所在的授权边界。一个跑在自己 VPS 里的普通用户，能读写宿主机的内存、让整台物理机宕机、甚至以管理员权限执行命令，同宿主机上的其他租户一起遭殃。AV:L 也不代表“本地才能利用”，官方说明写得很清楚：这是客人机到本地的虚拟设备路径，不是互联网接收路径，只要能通过自己被分配的 virtio-net 接口发包，就构成触发条件，不需要宿主机凭据，也不需要访问 /dev/net/tun。
你的 VPS 在哪一边：受影响版本区间与自查命令
CVE 记录里给出的受影响范围起点是 2.6.27，引入该逻辑的提交是 f43798c27684。上界按分支分开写，6 条稳定分支的修复版本如下表。这张表来自 CVE 官方记录中的 lessThanOrEqual 字段，含义是“该分支上到这个版本为止才算修好”。
| 内核分支 | 修复版本 | 含义 |
|---|---|---|
| 5.10.x | 5.10.272 | 低于此版本受影响 |
| 5.15.x | 5.15.223 | 同上 |
| 6.1.x | 6.1.190 | 同上 |
| 6.6.x | 6.6.159 | 同上 |
| 6.12.x | 6.12.113 | 同上 |
| 6.18.x | 6.18.57 | 同上 |
| 7.x | 7.2.11 与 7.3 | 以 7.2.11 和 7.3 为 不包含上界 |
在自己机器上核对只需要一条命令：uname -r。如果输出落在上表任何一个“低于”区间，那么这台客人机自身在打上内核补丁之前，也带着一份可以被滥用的代码路径，只是能不能利用取决于你在不在宿主机上，以及宿主有没有修。还有一个容易忽略的点：客人机的内核版本和宿主机完全无关，商家开给你的镜像可能是 5.15.0-xx 的企业内核，而宿主机跑的是另一条线，两者互不透露。所以你核对 uname -r 只能得出“我这台自己也不干净”，得不出“我的宿主机已经修了”。
需要换机器或者新开一台做对照时，挑选的重点放在能不能在商品页直接看到端口、流量与机房位置这三项，因为这三项决定你后续排查时有没有可比较的基准：看丽萨主机 KVM 套餐的端口与流量明细。推广链接，价格以商家页面为准。
升级内核解决不了：修在下面那一层，而你手上没有那把钥匙
这是整件事最容易被误解的地方，也是各类“一键修复教程”最容易写错的地方。CSO Online 在 10 月 20 日的报道里写得很直白：管理员必须在宿主机上部署内核更新，因为只更新客人机不能修复这个漏洞。理由回到机制上就通了：skb_checksum_help() 是在宿主机内核里执行的，被篡改的 IPv4 头也是在宿主机上被重新分片的。客人机里那段代码只是发出带毒元数据的发包方，把发包方修好，不代表接收方不再被污染。
对租户来说这意味着三件事，每件都要落到具体动作上，而不是“注意安全”四个字。
第一件：把“连不上”和“回不来”分开看待
A:H 那一项说明的是可用性影响，演示中可以做到让物理机宕掉，同宿主机上的所有沙箱一起消失。对租 VPS 的人来说，这种故障的形状是“商家层面重启”，你收到的通知可能是“节点维护”，也可能是没有通知。真正决定损失的不是故障本身，而是你在故障窗口里丢失了多少不可重建的状态。可以把风险折算成一个简单的问题：假设这台机器现在原地消失两小时，你的服务能靠外部副本恢复吗？能，就只需要接受停机；不能，那就是在这条漏洞之前你自己的架构问题。
具体的可迁移底线有两条：业务数据不要只存在这台机器的本地盘上，至少每天一次异地快照或逻辑备份，并验证过能恢复；接入层不要把所有域名硬指到一个 IP，准备一个可在十分钟内切换的记录。这两条与漏洞无关也能救命，但这次事件提醒的是它们不能靠“商家会负责”替代。
第二件：检查商家到底有没有重启过宿主
内核补丁要生效，宿主机必须重启，这一步会在你自己的 uptime 上留下痕迹，是少数你能观察到的商家侧动作。方法是记住自己机器的启动时间与内核版本，隔几天再看一次。如果商家只是因为漏洞重启了宿主，而你的实例没有跟着重建，理论上不该断线；如果你在某天发现机器无故短暂中断、之后一切正常，那可能就是宿主重启。想主动核对，可以看这几个信号：
uptime -s 给出系统启动的确切时间；last reboot | head 从 wtmp 里读重启记录；dmesg -T | head -20 能看到本次启动的早期信息与时间戳。虚拟机被宿主整体迁移或重启时，这几个时间点会和你的账单周期、商家公告对不上，对不上的那一次就值得记下来。需要说明的是，这些信息只能证明你的实例重启过，无法证明宿主内核已升级，宿主侧对租户不透明，这是租 VPS 这件事的固有边界，不必假装能绕开。
第三件：别把 /dev/kvm 当玩具开给不信任的负载
这条针对的是另一类人：买独服或大内存 VPS，自己在里面跑 KVM、给下属或客户开小虚拟机。此时你的身份从“租户”变成了“宿主”，上面那条“修不了”的结论就反过来了，你能修，而且必须修。判断自己是不是宿主的办法很简单，看 ls -l /dev/kvm 是否存在且可读写，以及 systemd-detect-virt 的返回值：输出 kvm 说明你在别人下面，输出 none 或 bare 说明你就是最底层。
对宿主角色，补救是把内核升到上表对应分支的修复版本并重启，然后核对 uname -r 的返回值确实变了。这里有一个实际存在的坑：某些发行版的安全更新会先发布包而不自动重启，机器看起来“已经是最新”，跑的却还是旧内核，uname -r 与 dpkg -l | grep linux-image 给出的版本号不一致就是证据。另外，如果宿主上跑了 Docker 或别的虚拟化层，注意这条漏洞的作用面是宿主的 IPv4 网络栈，容器共享宿主内核，因此宿主不修，容器里也谈不上安全。
为什么这次比前两次更值得重视：三个月内的第三个逃逸
把时间线摆出来，判断会清楚一些。根据公开梳理，2026 年 6 月到 9 月之间，KVM 已经有三次独立的客人机到宿主机逃逸被披露，再加上这篇里的 CVE-2026-99999，密度明显高于往年。同一条信息里还有一句更关键的观察：这个漏洞不在 KVM 模块本身，而在 Linux 的网络栈，因此同样的缺陷形态可能出现在其他虚拟化与沙箱平台里。
为什么这类漏洞会变多，有一个不太需要猜测的解释：virtio 这类半虚拟化设备把大量决策权交给了客人机，为了性能又尽量少做校验，“信任客人机的元数据”是设计上的常态。校验和卸载只是其中一处。对采购方来说，结论不是“别用 KVM”，KVM 仍然是绝大多数性价比 VPS 的底座，而是把“上游是否及时打补丁”当成一项可以问、可以比较的服务指标，而不是当成运气。
顺带说明一个常见误解。有人认为“我买的是独服，不共享宿主，所以与我无关”。独服确实消除了同宿主机其他租户这个攻击者，但如果你在独服上开 KVM 给客户用，你本人就是那个需要打补丁的宿主；如果你只是自己跑业务、不开虚拟化，那么这条漏洞对你几乎没有可执行的动作，剩下的是常规的对外服务加固。区分清楚自己站在哪一边，比笼统地“关注安全公告”有用得多。
下单前的问价清单：把这条问题写进工单
既然宿主版本对租户不可见，能做的就是把它变成采购时的问句。下面几条按重要性排列，都可以直接复制进工单。第一，节点使用哪条内核分支，最近一次安全内核升级是什么时间。第二，安全更新后是否会主动重启宿主，重启提前多久通知，是否提供同机房迁移以避开重启。第三，是否有独立于宿主机的快照或备份产品，恢复粒度是整机还是单盘。第四，出现宿主级故障时，SLA 的赔付是按可用性折算还是按单次事故定额。第五，若你在其上再开虚拟化（即你成为宿主），商家是否允许，是否有 CPU 虚拟化指令透传。
这五条里，前两条决定了你能不能把这次漏洞的风险转移给商家；第三条决定了出事时损失多少；后两条属于长期成本。多数商家的商品页不会写这些，但客服答得出来与答不出来本身就是信息。答不上来，通常意味着这家没有把这套流程固定下来，而不是藏了什么。
如果你现在正要选一台跑长期业务的机器，可以把这类“平台侧是否透明”的维度放进同一张比较表里。比如丽萨主机的产品卡明确标注 KVM 架构与机房位置，机器本身的规格与价格都在页面上，适合先把预算和规格对齐，再拿上面的问题去问宿主侧的事：查看丽萨主机各线路 KVM 套餐的规格与月费。推广链接，实际价格与库存以商家页面当日显示为准。
租户侧的四条硬结论
把整件事压成可以照着执行的判断，一共四条。
一，先在客人机里核对 uname -r，落在受影响区间就自己先升级重启，这一步只解决“我这台不干净”，别指望它解决宿主。二，把不可重建的状态移出这台机器，并真的恢复一次，验证比备份本身更重要。三，用 uptime 与 dmesg 时间戳观察宿主重启，这是租户能看到的唯一商家侧证据，看到异常重启就记录并与商家公告核对。四，如果你自己是宿主，立刻核对内核与包版本是否一致，不一致说明只装了包没重启，补丁尚未生效。
还有一条不算结论但值得记住：这次事件里，公开报道确认了漏洞的存在与修复，但并没有公开显示有租户因此被真实入侵的案例，Vercel 也表示没有报告显示客户文件、密钥或应用数据被访问。研究人员的演示是在受控环境里完成的，地下利用被预期会在数周内出现。这个区别在写采购判断时很重要：当下的风险是“未修补的宿主迟早会被利用”，不是“已经大规模发生”，按前者做准备，不要按后者恐慌，也不要按后者说“什么都没发生”。
资料来源
CVE-2026-99999 官方记录（CNA：kernel.org，2026 年 10 月 15 日发布，10 月 24 日更新，CVSS 9.3）：cve.org 上的 CVE 记录。机器可读记录（含受影响版本区间与修复提交列表）：cveawg.mitre.org 的 CVE JSON。
CSO Online，Lucian Constantin，2026 年 10 月 20 日《KVM escape exposes broader attack surface in Linux networking》：文章链接。内核修复提交可从 CVE 记录的 references 字段逐条打开 git.kernel.org 对应页面核对。
商家侧的 KVM 架构标注取自丽萨主机与易科云的购物车页面，抓取时间 2026 年 11 月 6 日；本文不对任何具体商家的宿主内核状态做判断，商品规格与价格以商家当日页面为准。
用户评论