上游修完七周，Ubuntu容器逃逸利用已公开

上游内核在8月6日就修好了，公开的容器逃逸利用代码却在9月22日才发布。中间这七周，Ubuntu的补丁没有跟上。

安全公司DepthFirst公开了CVE-2026-80521的可运行利用代码，针对的是Linux内核AF_UNIX套接字子系统中的堆释放后使用（use-after-free）漏洞，演示环境为Ubuntu 26.04 LTS。截至9月24日，Ubuntu安全跟踪页面上，26.04的主内核包状态仍写着“Vulnerable, work in progress”，24.04同样列为受影响，AWS、Azure、GCP的内核变体也在其中。

漏洞本身并不稀奇，内核里的释放后使用是常规故障。真正值得盯住的是时间线：

• 7月24日，DepthFirst凭这个零日拿到谷歌kernelCTF名额；
• 8月5日，报告给内核安全团队，对方回复OpenAI的Kyle Zeng已独立报告同一漏洞；
• 8月6日，上游修复落地；
• 9月22日，DepthFirst发布分析文章与利用代码；
• 9月24日，Ubuntu跟踪页面仍标注受影响。

修复提交的标题直白得近乎说明书：“af_unix: Unlink scc_entry in unix_del_edge()”，提交号594d905，位于net/unix/garbage.c。问题出在AF_UNIX的垃圾回收器里：进程通过SCM_RIGHTS消息传递文件描述符时，内核先把新的图边发布给回收器，几个指令之后才把承载它的套接字缓冲区入队。由于unix_add_edges()会获取并释放unix_gc_lock，回收器可以插进发送路径，看到一条所属缓冲区尚未入队的边。若回收器此时判定某个强连通分量已死，就会释放其中一部分，却没有把顶点从常驻的scc_entry环上摘下来。同一分量里幸存的套接字仍指向已释放内存，下一轮回收沿陈旧环遍历时便解引用了这块内存。

可达性是这件事的另一半。AF_UNIX套接字和SCM_RIGHTS描述符传递在默认的Docker与Kubernetes seccomp配置里是被允许的，属于标准容器内的常规操作。利用链不需要CAP_SYS_ADMIN，不需要特权标志，不需要加载内核模块，也不需要改动seccomp。它一次绕过命名空间、cgroup限制和seccomp过滤，因为被破坏的结构是共享的内核状态。DepthFirst还指出，nsjail、Firejail、Bubblewrap同样依赖这个子系统，基于内核的操作系统级沙箱也在暴露面内，不只是Docker和Kubernetes。

截至目前，没有确认的野外利用，CVE也未进入CISA的已知被利用漏洞目录。但公开的利用代码、最新的LTS发行版、上游已修复而发行版未跟进，这三件事凑在一起，性质就变了：一个不具备特殊技能的操作者，每天都能拿已发布的利用去打生产主机。

DepthFirst没有靠人眼审代码找漏洞，用的是内部训练用于漏洞检测的AI模型dfs-large1，配合人工操作的测试框架。该公司对威胁模型的表述很直接：“攻击内核以逃出容器的门槛已经下降到如此程度，我们必须假设攻击者可以随意为之。”它给出的数字是：2026年1月至9月中旬，公开的Linux内核CVE共5,976个，仅8月就达到1,650个。谷歌kernelCTF项目公开披露的36个CVE中，有13个可从默认暴露给容器的子系统中的普通非特权接口触达。

容器与宿主机共享同一个单体内核，这是设计使然。内核每年公开数千个漏洞，其中不少能从默认容器系统调用触达，而AI加速的发现流程正在压缩“漏洞存在”到“可用利用公开”之间的时间。按发行版内核打补丁、等USN通知的老办法依然有效，只是它现在运行在攻击者的时间尺度上——公开利用代码可能比发行版修复早数周出现。

在发行版补丁未出、DepthFirst与Canonical均未发布缓解措施的情况下，结构性对策只有一条：不再让不受信任的工作负载共享内核。DepthFirst的建议是把不受信任和多租户工作负载迁到microVM，例如Firecracker（AWS Lambda与Fargate在用）或Kata Containers。每个microVM拥有自己的轻量客户机内核，即便内核利用成功，也只影响那个临时实例，宿主机与相邻租户不受牵连。

必须留在容器里的部分，检查清单不长：确认节点实际运行的Ubuntu内核变体——22.04的原始内核不受影响，但基于6.8的HWE内核和22.04的云内核受影响，24.04与26.04的主线变体均受影响；发行版滞后且能测试重建的话，直接打上游补丁；盯住Ubuntu安全公告里的内核USN，把重启窗口当作紧急事项而非排期事项；如果负载本身不受信任——第三方代码、客户代码、任何多租户场景——先问一句：它真的需要共享内核吗。