Ubuntu 容器逃逸利用公开，补丁仍有空窗

上游已经修好漏洞，Ubuntu 的发行版内核却还没跟上，公开的容器逃逸利用先到了。原文围绕 CVE-2026-80521 提出一个判断：运行不可信代码时，不能只靠容器与宿主机共享的 Linux 内核承担隔离责任。

值得读的是这条修复时间线，以及默认容器为什么能触达漏洞。需要保留疑问的，则是作者把个案推广为「容器安全边界时代结束」的力度。以下状态均按原文记录转述，不代表今天的补丁情况。

上游修好了，为什么生产机器仍然暴露

据原文，DepthFirst 在 2026 年 7 月 24 日凭这个漏洞获得 Google kernelCTF 名额，8 月 5 日报告给内核安全团队。团队回复称，OpenAI 的 Kyle Zeng 也独立报告了同一个问题。8 月 6 日，上游修复落地。

但上游合入代码，不等于发行版已经完成回移、测试和软件包发布，更不等于生产节点已经重启进入修复后的内核。

9 月 22 日，DepthFirst 公开研究和可运行的利用代码，并在 Ubuntu 26.04 LTS 上演示容器逃逸。原文称，截至 9 月 24 日，Ubuntu 安全跟踪器仍把 26.04 的主内核包标为「Vulnerable, work in progress」，24.04 及两者的 AWS、Azure、GCP 内核变体也在受影响范围内。

这篇文章最有分量的证据，是上游修复与发行版交付之间约七周的窗口。

原文另附一张标注为 9 月 29 日截取的跟踪器截图，显示 CVSS 评分为 7.8、等级 High，Ubuntu 优先级为 Medium。它与正文反复使用的 9 月 24 日观察点并不一致，阅读时应分开看，不能把这些日期拼成经过持续验证的状态记录。

原文同时明确：发表时没有确认的野外利用证据，也没有进入 CISA KEV 已知遭利用漏洞目录。公开利用提高了风险的现实性，但不能据此声称已经发生大规模攻击。

默认容器为什么能碰到这个漏洞

漏洞位于 Linux 的 AF_UNIX socket 子系统。它负责本机进程间通信，SCM_RIGHTS 则允许进程通过消息传递文件描述符。内核需要跟踪这些引用，并清理循环依赖，出错的正是这部分垃圾回收逻辑。

这里的垃圾回收不是 JavaScript GC，而是内核维护 socket 引用关系的机制。

按原文描述，发送文件描述符时，scm_stat_add() 先调用 unix_add_edges()，让新的引用关系对回收器可见，承载这些引用的缓冲区却要稍后才由 __skb_queue_tail() 入队。unix_add_edges() 会获取并释放 unix_gc_lock，于是中间出现竞态窗口：回收器已经看见引用边，却还看不见对应的队列缓冲区。

如果此时回收器判定一个强连通分量，也就是一组相互可达的节点已经失效，unix_del_edge() 和 unix_free_vertices() 可能释放其中的对象，却没有把节点从持久的 scc_entry 环中摘除。同组仍存活的 socket 保留着旧指向，下一轮 unix_walk_scc_fast() 遍历时就可能访问已经释放的内存，形成堆释放后使用（heap use-after-free）。

修复名直接点出了问题：「af_unix: Unlink scc_entry in unix_del_edge()」。修改位于 net/unix/garbage.c，提交短标识为 594d905，完整标识为 594d905195024b228c962627ae5ae7c17bd582a4。

这对容器的影响来自接口可达性。按原文，Docker 和 Kubernetes 的默认 seccomp 配置允许 AF_UNIX 与 SCM_RIGHTS，利用不需要 CAP_SYS_ADMIN，不需要 privileged 标志，也不需要加载内核模块或修改 seccomp。

namespace 隔离资源视图，cgroup 限制资源使用，seccomp 筛选系统调用。这些机制无法保证一个被允许调用的内核接口内部没有内存错误。攻击一旦触及共享内核状态，容器内部的操作就可能影响宿主机。

原文还指出，nsjail、Firejail、Bubblewrap 同样依赖这个子系统。不过，具体部署能否利用，仍不能仅凭产品名判断。

AI 找漏洞更快，能证明容器已经失效吗

DepthFirst 称，漏洞由其内部漏洞检测模型 dfs-large1 配合人工操作的测试框架发现。这里有模型参与，也有人工验证，原文没有提供足够信息来拆分两者各自完成了多少工作。

文章给出两组数字：2026 年 1 月至 9 月中旬，共发布 5,976 个独立 Linux 内核 CVE；其中 8 月发布 1,650 个，占同期总数超过 27%。Google kernelCTF 公开披露的 36 个 CVE 中，13 个可通过容器默认暴露的普通、非特权接口触达。

后一组数据更直接关联容器风险：有些漏洞的入口，确实属于普通容器可以使用的能力。前一组只能描述 CVE 发布规模，不能单独证明 AI 让漏洞产生或发现得更快。文章没有给出 AI 发现占比、历史对照，也没交代披露与编号节奏的影响。

DepthFirst 因此建议，把不可信和多租户工作负载迁到 Firecracker、Kata Containers 等 microVM 方案，让每个工作负载使用独立的客户机内核。原文以 AWS Lambda、Fargate 使用 Firecracker 作为例子。

这个建议改变的是故障波及范围：攻破客户机内核之后，还隔着虚拟化边界，才能继续影响宿主机或邻近租户。

但原文没有给出迁移前后的性能、成本和兼容性数据，也没有证明 microVM 可以免疫所有逃逸路径。「独立内核增加一道边界」成立，「攻破后宿主机必然安全」则说得过满。

我的判断

我认同文章对共享内核风险的提醒，尤其适用于执行第三方代码、客户代码和多租户任务的平台。对于这类业务，隔离边界本来就应按「工作负载可能主动攻击宿主机」来设计。

但「容器不再是安全边界」更像一个推动读者重新评估架构的标题。容器仍然提供隔离能力，只是它依赖宿主内核正确工作，也受接口暴露范围影响。这个漏洞揭示了依赖关系，不能独自证明所有容器部署都失去了价值。

CVE 发布数量不能直接证明 AI 导致容器失守，也不能换算成生产环境的可利用概率。

与继续加固共享内核容器相比，microVM 把工作负载内核与宿主内核分开，方向更贴合恶意代码执行场景；但文章没有提供对照测试，无法回答具体团队为此要付出多少启动、资源和运维成本。

作者把 microVM 称为唯一的结构性缓解，也需要收窄理解：不再与不可信任务共享宿主内核，是其建议的核心。原文没有穷尽其他隔离方案，更没有给出全面比较。

另一个不能照抄的结论是「所有内核漏洞都等于容器逃逸」。还需要满足入口可达、权限条件和可利用性等前提。这次案例的关键，恰恰是作者报告这些前提在默认容器里能够成立。

能拿来做什么

• 如果你维护 Node 服务或 Kubernetes 节点，先盘点实际运行的内核版本和变体，再核对修复状态。按原文记录，Ubuntu 22.04 的标准内核不受影响，但基于 6.8 的 HWE 和相关云内核受影响，不能只看发行版名称。
• 如果平台会执行客户脚本、第三方构建任务或 AI 编程代理生成的代码，应把它们按不可信工作负载评估。将 microVM 列入隔离方案比较，并验证启动耗时、资源开销和现有工具链兼容性。
• 如果暂时继续使用容器，把发行版内核公告、补丁安装和重启切换连成一个处理流程。原文建议关注 Ubuntu 的 USN；如果考虑自行应用上游补丁，也要先具备重建和测试能力，不能把上游已修复当作节点已修复。