云主机里的租户，能读到同一台宿主机上别人的内存

原创

tcode
tcode

字节脉搏实验室

2026年10月16日 10:32
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

10月15日，编号CVE-2026-99999、被研究者称为PwnEscape的Linux内核漏洞进入公开视野。它做的事情一句话能说清：跑在虚拟机里的代码，可以读到它所在这台物理机的内存。安全公司pwn.ai的研究员Paulos Yibelo用特制网络数据包做了演示，其中内存泄露这一项在Vercel的生产沙箱环境中被验证，Vercel随后确认了这一点。

对使用云主机、虚拟化平台或自建私有云的团队来说，这件事的处置顺序与常见的补丁通知不同：需要升级的是宿主机上的内核，虚拟机内部的内核升不升，对这个漏洞没有影响。

被标成“本地”的漏洞，为什么仍要排期

NVD把这处漏洞的攻击向量标为“本地”，含义是攻击者必须先能在虚拟机里执行代码，不能在公网上直接发包打进来。这一条经常被读成“风险不大”，但在多租户环境里，它恰好是最需要认真对待的那类条件。

共享云的隔离模型本来就假设租户的工作负载不可信——任何能拿到一台云主机、一个函数计算实例或一个沙箱环境的人，都已经满足了“在虚拟机里执行代码”这个前提，剩下要做的只是从这一层往宿主机走。按公开描述，每个数据包可以带回约32字节的宿主机内存，持续发包就能持续读；两个特制数据包可以导致宿主机崩溃，随之宕掉的是这台机器上运行的全部沙箱。读内存这一项在云厂商的生产沙箱上被验证，崩溃和在宿主机上执行代码这两项只在研究者自己搭建、配置与生产环境一致的机器上观测到，研究者本人也强调这不是“在任意厂商的生产环境里拿到了root”。

内核侧给出的官方描述印证了机制：出问题的是IPv4校验和完成路径，校验和元数据异常的报文进入ipv4协议栈后，可能损坏网络头部。虚拟机侧发出的报文，正是经由宿主机的内核网络处理路径进入这段代码的。

从发现到披露的四个时间点

把这处漏洞的公开信息排成时间线，能看清它现在的状态。2026年8月，一家云平台举办为期两周的安全挑战赛，总奖金池最高100万美元，用来奖励突破其沙箱的研究；赛事最终收到1285份有效报告，总计发放24.2万美元奖金，单份报告最高5万美元，本次这处漏洞是其中唯一的严重级别发现。研究团队称，他们用自研的AI辅助研究系统在3天内定位到缺陷，研究过程消耗的接口成本不到700美元，模型负责源码分析、研究员主导方向。2026年10月15日，NVD收录该漏洞，状态为“已接收”，同日公开材料陆续发布。也就是说，从内部上报到公开披露经过了大约两个月，而补丁在披露前已经进入主线并回移到各稳定分支——这是负责任披露流程应有的样子，也意味着“现在才看到通知”的团队，落在信息链的最后一环。

门一：版本线要按分支对照

官方修复是一处单点修改，提交号为6785011f8b16，由红帽的Michael S. Tsirkin编写，已合入内核主线。补丁加的逻辑是在内核完成校验和之前，先确认校验和起始位置不会指向IPv4头部，覆盖网络代码中的5处位置。公开材料把这个补丁称作一项“纵深防御措施”：它堵住已知路径，而不是对进入内核的全部路径做完整校验，更完整的入口校验仍在开发中。

按公开的修复记录，各受支持稳定分支的首个修复版本分别是5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57和7.2.11。这张表是判断“我这台机器算不算已修”的第一把尺子，但不是唯一一把。

门二：发行版公告比 uname 里的版本号更可信

Linux发行版会自行编译内核，通常在不改变版本号的情况下把这类修复合进去。所以显示在系统里的内核版本号，既可能高于修复线却仍缺这个补丁，也可能低于修复线但已经打过补丁。正确做法是以你所用的发行版——包括国内厂商维护的发行版分支——的安全公告为准，逐条确认这个修复合没合进你机器上运行的那个内核包，而不是拿上游的版本表直接比对。

这一步对国内的自建虚拟化平台尤其重要：很多企业用的是长期维护版内核，版本号几年不动，安全修复靠回移补上，只看版本号会得出“早就安全了”的错误结论。

门三：要动的是宿主机

这一点最容易在排期时搞错。漏洞位于宿主机运行的内核网络代码里，升级虚拟机内的内核不能修复它；宿主机内核必须在升级后重启才生效。官方目前没有给出单独的临时规避方案，也就是说，在补丁到位前的窗口期里，没有一条“改个配置就安全”的捷径。

如果重启窗口一时排不上，公开材料给出的方向是缩小“被利用之后能做什么”的范围：禁用嵌套虚拟化，并让承载微虚拟机或容器的进程只保留运行必需的权限。这类措施不修复漏洞本身，只是把损失上限压低，不能当作升级的替代品。

今天的处置顺序

第一步，把宿主机——不是虚拟机——的内核版本、发行版与内核包版本盘出来，按宿主机分组，并注明每台机器上跑了多少租户。一个实用口径是：一台宿主机上的租户越多，排期优先级越高，因为崩溃和逃逸的影响面按这台机器上的全部工作负载计算。

第二步，拿这份清单对照你所用发行版的安全公告，而不是对照上游稳定分支的版本表。公告写明包含该修复的记已修；公告未提及的，不要默认安全。

第三步，排升级窗口。重启宿主机意味着其上所有虚拟机一起重启，这是这项工作真正的成本，也需要由业务连续性和与租户的约定来定；暂时排不上的机器，先按门三里说的方式限制影响范围，并单独登记，避免在下一次盘点里漏掉。

第四步，升级前后各留一条日志线索。宿主机内核的崩溃、重启与异常日志，是判断“有没有被人从虚拟机侧触发过”最直接的记录；如果此前出现过无法解释的宿主机重启，需要把它和这台机器上租户的时间点交叉核对。

核查是否已经修复，除了版本和公告，还有一条常被忽略的记录：内核包自身的更新说明。多数发行版的安全更新会写明对应的缺陷编号或上游提交，把这行记录和上面那个提交号对上，比凭印象判断可靠。内核崩溃转储、重启记录与内核参数的变更历史，也建议在这次排查里一并导出，作为后续复核的基线。

责任边界要提前说清楚：宿主机内核属于平台侧资产，租户能做的通常只是把自己的负载迁走或推迟上线。如果你的业务跑在别人的虚拟化平台上，这条通知的正确用法是向平台方确认修复状态与时间表，而不是在自己的云主机里升级内核。

边界

公开材料没有给出真实攻击案例，该漏洞也不在在野利用漏洞目录里，目前处于“已披露、已修复、未见在野利用”的状态：不需要按已失陷处理，但需要按可被利用的资产登记。演示中读取的内容是研究者自己控制的沙箱数据，云厂商表示挑战赛的报告中没有任何一份显示研究人员读到了客户文件、密钥或应用数据——这句话说明的是“没有发现”，不是“不可能发生”。把“本地向量”理解为“只有内部人员才能利用”也不准确：在多租户平台上，任何一个租户的身份都满足这个前提。

判断一台宿主机要不要今晚排期，一句话就够：它运行的内核是不是已经落在所用发行版公告写明的修复线上，而这台机器上还跑着别人的负载。

来源

NVD 记录 CVE-2026-99999（ipv4 校验和路径缺陷，状态 Received），发布 2026-10-15 13:17:14，最后修改 2026-10-15 23:19:38。https://nvd.nist.gov/vuln/detail/CVE-2026-99999

The Hacker News《Critical PwnEscape Linux Kernel Vulnerability Lets Guest VMs Read Host Memory》，Swati Khandelwal，2026-10-15（页面未标注时区）。https://thehackernews.com/2026/10/critical-pwnescape-linux-kernel.html

FreeBuf《Linux内核PwnEscape高危漏洞曝光，虚拟机可读取宿主机内存》，2026-10-16 01:54:36（中文报道，转述厂商与研究方公开材料）。https://www.freebuf.com/articles/system/506832.html

研究方技术分析文章入口（Paulos Yibelo，pwn.ai），由 The Hacker News 引用；本次未直接取到该页正文。https://pwn.ai/blog/Pwnescape

新建一个吹水群，主要针对转行和失业的兄弟姐妹们吐槽，互助跳出抑郁情绪和环境。