一小时扫描挖出七年老漏洞：Linux内核的"复制失败"

2017年以来的每一台Linux服务器，都可能被732字节的Python代码攻破。这不是演习——安全公司Theori用AI扫了一小时，就找到了这个潜伏七年的"复制失败"漏洞。

一个命名很诚实的漏洞

漏洞代号CVE-2026-31431，研究人员给它起了个直白的外号："Copy Fail"（复制失败）。名字来源于Linux内核的splice()系统调用——这个设计用来"零拷贝"传输数据的机制，反而成了攻击者的跳板。

Theori的研究人员发现，问题藏在authencesn加密模板里。这是个处理认证加密数据的内核组件，本该确保数据完整性，却允许认证用户向系统上任何可读文件的页缓存写入4个字节。

4个字节能干什么？如果这4字节精准命中一个设置了setuid-root权限位的二进制文件，就能篡改它的执行逻辑。下次有人运行这个文件时，攻击者就拿到了root权限。

漏洞影响范围堪称"全覆盖"：Ubuntu、Amazon Linux、RHEL、SUSE全部中招。所有2017年后发布的Linux内核版本都存在这个问题。

攻击链拆解：三件套组合技

这个漏洞的精巧之处在于，它不需要复杂的竞争条件（竞态攻击），也不用针对特定内核版本硬编码偏移量。BleepingComputer的分析揭示了攻击路径：

第一步，利用AF_ALG套接字接口。这是Linux从用户空间访问内核加密功能的通道，原本的设计意图是让应用程序能调用内核级的加密算法，而不必自己实现。

第二步，调用splice()系统调用。这个调用的设计目标是在内核地址空间内部移动数据，避免数据在用户空间和内核空间之间来回拷贝——也就是所谓的"零拷贝"优化。

第三步，把这两样东西串起来。正常情况下，splice()应该把数据从一个文件描述符搬到另一个。但当源端是AF_ALG套接字、且使用了有缺陷的authencesn模板时，数据目的地变成了页缓存本身，而且写入位置可以被精准控制。

Theori的描述很技术化："a straight-line logic flaw"——直线路径逻辑缺陷。翻译成人话：攻击代码按顺序执行就能成功，不需要碰运气等竞态窗口。

AI挖洞：一小时 vs 七年

这个漏洞最讽刺的细节是发现方式。Theori没有派出一队安全研究员手工审计代码，而是动用了自家产品：Xint Code，一个AI驱动的渗透测试平台。

任务目标很明确：扫描Linux加密子系统。扫描时间很具体：一小时。

结果就是一个影响全球数百万台服务器、潜伏七年的高危漏洞。732字节的Python利用代码，从扫描到武器化，效率堪称恐怖。

这引出了一个尴尬的问题：Linux内核的代码审计流程，在AI面前显得有点慢。不是内核开发者不专业——authencesn模板的问题确实隐蔽，涉及splice()和加密子系统的交互边界。但AI的扫描速度和覆盖范围，确实改变了漏洞发现的成本结构。

容器环境尤其危险。很多云原生部署共享同一个内核，一旦宿主机内核有漏洞，所有容器都暴露在横向移动的风险下。传统的"容器隔离"假设，在这种内核级漏洞面前形同虚设。

修复现状与行动清单

好消息是补丁已经可用。主流发行版都发布了安全更新，坏消息是打补丁需要重启——对追求高可用的生产环境来说，这永远是道选择题。

如果你管理Linux服务器，现在该做的事：

确认内核版本。2017年之后的全部在风险范围内，不要心存侥幸。

检查发行版安全公告。Ubuntu、RHEL、SUSE、Amazon Linux都有对应的CVE-2026-31431补丁包。

评估重启窗口。如果暂时无法重启，考虑限制本地用户权限、监控可疑的AF_ALG套接字使用——但这只是缓解，不是根治。

容器用户额外注意：宿主机内核是共享的，打补丁优先级应该高于容器镜像更新。

这个漏洞的命名"Copy Fail"带点黑色幽默——本意是加速数据传输的零拷贝机制，反而成了权限提升的捷径。技术债的偿还方式总是出人意料，而AI正在加速账单的到来。