AI 漏洞挖掘时代来了：Copy Fail、Dirty Frag、Fragnesia 与 ssh-keysign-pwn 为何集中爆发

Thu, 21 May 2026 09:30:01 +0800

最近一段时间，Linux 内核相关漏洞密集出现：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwn 接连进入安全圈讨论。它们有的可以本地提权，有的能泄露高敏感文件，有的影响容器宿主机和多租户环境。很多人的第一反应是：Linux 怎么突然变得这么不安全？

更准确的说法是：Linux 不是突然变差了，而是隐藏很久的问题被更快、更系统地挖了出来。

这轮事件真正值得关注的，不只是某几个 CVE 的修复，而是漏洞发现方式变了。过去需要少数顶级研究员花很久才能串起来的跨子系统逻辑漏洞，现在正在被 AI 辅助审计、自动化静态分析、模糊测试和安全研究平台批量放大。漏洞没有一夜之间多出来，但漏洞被发现、被复现、被扩散的速度变快了。

这几次漏洞有什么共同点

先把最近几次事件放到一张表里看。

漏洞	主要影响	关键特征	风险重点
Copy Fail / CVE-2026-31431	本地提权	Linux crypto / AF_ALG 相关路径，涉及 page cache 写入问题	普通用户到 root，容器环境尤其敏感
Dirty Frag / CVE-2026-43284、CVE-2026-43500	本地提权	XFRM/ESP、RxRPC 等路径里的 page cache 写入原语	可链式利用，影响宿主机与容器边界
Fragnesia / CVE-2026-46300	本地提权	XFRM ESP-in-TCP 子系统逻辑问题	与 Dirty Frag 同属相近攻击面
ssh-keysign-pwn / CVE-2026-46333	本地敏感信息泄露与提权风险	Linux kernel `__ptrace_may_access()` 逻辑缺陷	SSH 主机密钥、`/etc/shadow` 等敏感文件风险

它们不完全是同一个漏洞，但背后有几个共同点：

都不是传统远程 RCE，而是本地权限提升或本地敏感信息泄露。
都要求攻击者先拿到某种本地执行能力，比如普通 shell、容器内命令执行、CI 任务权限或低权限账户。
多数风险集中在内核边界：page cache、加密/网络子系统、ptrace 权限判断、容器共享内核。
影响面会被现代云原生环境放大，因为容器不是强安全边界，宿主机内核仍然是共同底座。

所以问题不只是“有没有补丁”。更深的问题是：为什么这些看起来很底层、很隐蔽、潜伏很久的问题，会在短时间内集中出现？

第一层原因：很多漏洞是历史债，不是刚写进去

很多人看到漏洞披露时间，会误以为漏洞是在最近版本里新引入的。实际往往不是这样。

Copy Fail 这类问题的关键点在于：漏洞可以潜伏多年，直到有人把正确的调用路径、权限边界和内存语义串起来。公开信息显示，Copy Fail 与 2017 年前后的内核优化历史有关。Dirty Frag、Fragnesia 也都指向网络、加密、page cache 这类深层交叉路径。

这类漏洞的可怕之处，不是某一行代码看起来明显危险，而是多个前提刚好叠在一起：

某个子系统为了性能做了原地处理。
某个接口允许非特权用户触达内核功能。
某个路径把只读文件页、page cache、网络包片段、加密缓冲区连接到一起。
某个隐式约束没有写进类型系统、断言或文档。
最终形成“普通用户能影响本不该影响的内核状态”的路径。

这不是普通代码审查最擅长发现的问题。审查者可能懂 crypto 子系统，另一个人懂网络子系统，第三个人懂内存管理，但漏洞刚好藏在它们的交界处。

第二层原因：Linux 内核复杂度已经超出人工审查极限

Linux 的优势是开放、通用、硬件支持广、生态强。但这些优势也带来了代价。

现代 Linux 内核不只是一个“小内核”。它包含调度、内存管理、文件系统、网络协议栈、加密框架、驱动、虚拟化、容器相关机制、eBPF、LSM、安全模块、硬件平台适配等大量子系统。每个子系统都有自己的历史、维护者、性能目标和兼容性包袱。

问题在于，漏洞常常不在单个模块里，而在模块交叉点：

splice() 把文件页和管道连接起来。
AF_ALG 把用户态和内核 crypto API 连接起来。
XFRM/ESP 把网络包、加密和内存页连接起来。
RxRPC、ESP-in-TCP 这类路径让网络协议栈更加复杂。
容器让低权限本地执行变成更常见的现实前提。

从工程角度看，Linux 内核已经不是“足够多的眼睛就能看完”的规模。开源确实让问题更容易被修复和复核，但不等于每个角落都会被持续、安全地审查。真正能理解跨子系统漏洞的人很少，而这类漏洞偏偏最容易造成高影响。

第三层原因：性能优化经常把安全边界压得很薄

这轮漏洞里反复出现一个主题：为了性能减少拷贝、复用缓冲区、原地处理数据。

这类优化非常合理。内核是基础设施，性能差一点，云厂商、数据库、网络、存储、容器平台都会感受到。一次少拷贝、一次更快的加解密、一次更少的内存分配，都可能在真实生产环境中带来收益。

但安全代价也很清楚：当“只读数据”“共享页”“用户可控输入”“内核缓冲区”“加密输出”之间的边界变薄，只要某个子系统对输入输出契约理解不一致，就可能产生越权写入或越权读取。

也就是说，性能优化本身不是错，但它会制造更脆弱的组合：

原地加解密减少了复制，但也更依赖输入输出缓冲区的正确隔离。
page cache 提升了文件访问效率，但也可能成为攻击面。
零拷贝提升吞吐，但也让不同子系统共享同一批内存对象。
容器提升部署效率，但共享内核意味着本地 LPE 的爆炸半径更大。

安全边界不是靠“大家都记得别犯错”维持的。边界必须落实到类型、权限检查、不可变约束、测试、fuzzing 和持续审计里。否则，性能优化越多，隐式假设越多，漏洞迟早会被挖出来。

第四层原因：容器让本地漏洞的价值变高了

过去说“本地提权”，很多人会觉得风险低于远程漏洞，因为攻击者已经需要本地账户。但云原生时代改变了这个判断。

今天的“本地执行”来源太多了：

Web 应用被打出普通 shell。
CI/CD 任务执行了不可信代码。
容器里跑了用户上传任务。
多租户平台允许用户运行 notebook、插件、脚本或构建任务。
AI 代码执行环境、沙箱和在线评测平台越来越常见。

一旦攻击者在容器里有执行能力，内核 LPE 就不再只是“本机小问题”。因为容器共享宿主机内核，内核漏洞可能直接跨过容器边界，影响宿主机和其他租户。

这也是为什么 Copy Fail、Dirty Frag 这类漏洞会被云、安全、容器团队高度关注。它们把“低权限本地代码执行”升级成“宿主机级风险”的可能性提高了。

AI 的影响：漏洞发现成本被压低了

这轮事件里最有时代感的部分，是 AI 辅助漏洞挖掘。

Copy Fail 的公开资料提到，Theori 的 Xint Code 参与了漏洞发现过程。无论具体工具能力如何，这件事代表了一个趋势：AI 不一定自己“凭空发明漏洞”，但它很擅长帮助研究员缩短搜索路径。

AI 对漏洞研究的影响主要体现在几件事上：

更快扫过陌生代码
内核子系统代码量很大，研究员不可能手工阅读所有路径。AI 可以帮助快速总结函数、调用链、输入输出关系和可疑模式。
更容易发现跨模块连接
很多漏洞藏在“用户态入口 -> 网络栈 -> 加密框架 -> 内存页 -> 文件缓存”的链条里。AI 可以辅助梳理这些跨文件、跨目录、跨子系统的路径。
更容易生成审计假设
比如“哪些路径会把用户可控数据写入 page cache”“哪些 API 允许非特权用户触达 crypto 子系统”“哪些函数假设输入输出缓冲区不会重叠”。这些问题以前靠经验慢慢想，现在可以被更系统地枚举。
更容易把漏洞变成可复现样例
AI 不能替代内核研究员的判断，但可以帮助写验证代码、整理 PoC 思路、解释错误路径、生成测试用例。

结果是：漏洞挖掘的单位成本下降了。

过去，一个高质量内核漏洞可能需要很长时间才能被顶尖研究员发现。现在，懂系统的人加上 AI 工具，可以更快把可疑路径筛出来。漏洞供给的天花板被抬高，集中爆发就更容易出现。

但 AI 不是唯一原因

也要避免另一个极端：把所有问题都归因于 AI。

AI 只是加速器，不是漏洞根源。漏洞真正的根源仍然是：

历史代码长期累积。
性能优化中的隐式契约没有被强制化。
跨子系统复杂度太高。
默认暴露的内核功能太多。
安全测试没有覆盖所有组合路径。
容器、多租户和自动化执行环境扩大了本地漏洞价值。

如果没有这些基础条件，AI 再强也挖不出这么多高影响漏洞。反过来，只要这些条件存在，AI 越成熟，漏洞就越容易被系统性挖出。

对防守方意味着什么

对运维、安全和平台团队来说，这轮事件有几个直接启示。

第一，不要再把“本地提权”当低优先级。
只要你的环境里有容器、CI、在线执行、插件、notebook、多租户任务，本地提权就可能变成宿主机风险。

第二，内核补丁节奏要更快。
关键宿主机、Kubernetes 节点、CI Runner、AI 沙箱、虚拟化宿主机，不应该长期停留在旧内核。内核更新、重启窗口、live patch、灰度回滚都要有明确流程。

第三，减少不必要的内核攻击面。
不需要的协议、模块、用户命名空间、特殊 socket、调试接口，要按业务需要收紧。默认开启不等于默认应该暴露。

第四，容器安全要假设内核可能被打穿。
容器里使用非 root、最小 capabilities、seccomp、AppArmor/SELinux、只读文件系统、隔离敏感挂载，仍然很重要。它们未必能挡住所有内核漏洞，但能减少前置条件和后续破坏。

第五，监控要关注提权链条。
不仅要看远程入口，也要看异常进程、敏感文件读取、内核模块加载、容器逃逸迹象、CI Runner 异常行为、/etc/shadow、SSH host key 等高价值文件访问。

对开源社区意味着什么

对 Linux 社区和大型开源项目来说，AI 漏洞挖掘会带来双重压力。

一方面，AI 会帮防守方更快找到老问题。更多潜伏漏洞被公开修复，从长期看是好事。

另一方面，AI 也会制造噪音。低质量自动报告、误报、重复报告、没有上下文的“AI 找 bug”会消耗维护者时间。真正的挑战不是“是否使用 AI”，而是如何把 AI 输出纳入负责任的安全流程：

报告必须有最小复现。
必须明确影响范围和威胁模型。
必须区分理论问题、可触发 bug、可利用漏洞。
必须尊重 embargo、发行版协调和修复窗口。
维护者需要更好的自动化测试、fuzzing、静态分析和回归验证。

AI 让漏洞发现更快，也要求修复和协调机制更成熟。否则，安全研究的生产力提升会转化成维护者的压力和用户的恐慌。

结论：不是神话破灭，而是安全现实变了

Linux 仍然是最透明、最可控、最能被修复和加固的主流操作系统基础设施之一。问题不在于 Linux 突然“不安全”，而在于现代内核的复杂度、云原生使用方式和 AI 辅助漏洞挖掘，正在改变漏洞暴露速度。

以后类似事件很可能还会出现。不是因为每次都有新的灾难，而是因为过去积累的复杂路径正在被更高效率地搜索。

真正该改变的是我们的安全假设：

不能把“没披露漏洞”当作“没有漏洞”。
不能把“本地提权”当作低风险。
不能把“容器隔离”当作强安全边界。
不能只靠人工审查面对千万行级别系统软件。
不能只等补丁，而要提前缩小攻击面、加快补丁节奏、建立纵深防御。

AI 让漏洞挖掘进入更高产能时代。对攻击者是这样，对防守者也一样。区别在于，防守方能不能把这种能力变成更快的审计、更早的修复和更稳的基础设施治理。

Fragnesia on KnightLi的博客