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

从 Copy Fail、Dirty Frag、Fragnesia 和 ssh-keysign-pwn 四个近期 Linux 内核漏洞出发,分析为什么漏洞看起来突然变多,以及 AI 漏洞挖掘、历史技术债、内核复杂度和性能优化如何共同改变漏洞发现速度。

最近一段时间,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 对漏洞研究的影响主要体现在几件事上:

  1. 更快扫过陌生代码
    内核子系统代码量很大,研究员不可能手工阅读所有路径。AI 可以帮助快速总结函数、调用链、输入输出关系和可疑模式。

  2. 更容易发现跨模块连接
    很多漏洞藏在“用户态入口 -> 网络栈 -> 加密框架 -> 内存页 -> 文件缓存”的链条里。AI 可以辅助梳理这些跨文件、跨目录、跨子系统的路径。

  3. 更容易生成审计假设
    比如“哪些路径会把用户可控数据写入 page cache”“哪些 API 允许非特权用户触达 crypto 子系统”“哪些函数假设输入输出缓冲区不会重叠”。这些问题以前靠经验慢慢想,现在可以被更系统地枚举。

  4. 更容易把漏洞变成可复现样例
    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 让漏洞挖掘进入更高产能时代。对攻击者是这样,对防守者也一样。区别在于,防守方能不能把这种能力变成更快的审计、更早的修复和更稳的基础设施治理。

参考资料

记录并分享
使用 Hugo 构建
主题 StackJimmy 设计