732字节攻破Linux：一个AI发现的七年老洞

「用AI找漏洞的人，正在重新定义安全研究的节奏。」Xint Code团队这句轻描淡写的备注，让整个Linux生态在补丁周里手忙脚乱。

他们公开了一个存在了七年的内核漏洞。攻击代码只有732字节，却能让任何本地普通用户瞬间拿到root权限。更麻烦的是，披露窗口太短，各大发行版根本来不及反应。

一图读懂：这个漏洞到底怎么回事

先放下那张核心图——整个事件的技术链条其实不复杂，但每个环节都踩在了Linux架构的敏感神经上。

漏洞编号CVE-2026-31431，根因是密码学优化引入的代码缺陷。Linux内核的加密子系统为了性能，把一部分算法处理做成了可加载模块。问题出在algif_aead这个接口：它允许用户空间通过AF_ALG套接字与内核加密模块交互，但在权限校验上留了空子。

攻击路径很直接。普通用户打开AF_ALG套接字，请求aead（认证加密关联数据）服务，触发内核模块的特定代码路径。由于实现缺陷，内核在某些错误处理流程中错误地提升了进程权限——不是设计如此，纯粹是代码层面的疏忽。

732字节的攻击代码做了什么？它精心构造了一系列系统调用序列，触发那个有缺陷的错误处理分支。一旦成功，当前shell的uid就变成了0。不需要内存破坏，不需要ROP链，不需要任何现代漏洞利用的复杂技巧。这种简洁本身就说明了问题的严重性：攻击面太干净，防御层根本没设防。

影响范围是全覆盖式的。Ubuntu 24（26版上周刚发）、RHEL 10、Suse 16、Amazon Linux 2023，甚至Windows的WSL2都在名单上。2017年至今，几乎所有主流发行版都携带了这个缺陷。

为什么七年没人发现

这里有个反直觉的点。algif_aead不是冷门代码，它是Linux内核加密API的标准组件。每天有大量系统在用：TLS卸载、磁盘加密、VPN隧道，都依赖这套接口。

问题藏在「优化」两个字里。2017年的某次性能改进，重构了错误处理流程。代码审查时，所有人都在看正常路径对不对，没人想到异常分支会越权。这种模式在安全史上反复出现：性能压力下的重构，往往伴随着权限模型的隐性破坏。

Xint Code的披露策略也引发了争议。他们没有给标准的安全响应周期，而是快速公开。团队只解释了一句：用AI辅助发现的。这句话信息量很大——AI在代码审计中的角色，正在从「辅助工具」变成「发现主力」，而发现者的心态也在变化：既然AI能批量扫描，保密窗口期的价值在贬值。

两种应急方案，都有代价

如果你的内核把algif_aead编译成模块，解法相对干净。写一条modprobe规则，禁止加载这个模块，重启生效。代价是：任何依赖内核aead服务的应用会挂掉，比如某些配置下的IPsec、WireGuard。

RHEL和WSL2的用户更头疼。它们把algif_aead编进了内核核心，不是模块，没法卸载。这时候只能上强制访问控制：用seccomp掐掉AF_ALG套接字创建权限，或者配AppArmor/SELinux策略，禁止用户进程走这条路径。

这两种方案的共同问题是：它们都在破坏正常功能。Linux的加密子系统设计上就是给普通用户用的，现在为了安全要把它封死。多用户服务器、容器平台、CI/CD流水线，这些场景本来依赖内核提供的隔离和加密服务，现在要么冒险开着漏洞，要么亲手拆掉基础设施。

验证漏洞的指令，本身就是个信任陷阱

Xint Code给了一条测试命令：curl一个远程脚本，用python3跑，然后su。他们自己也备注了——「你在信任一个在线脚本」。

这几乎是安全研究者的黑色幽默。验证系统是否脆弱的行为，本身就引入了新的脆弱点。更谨慎的做法是下载他们发布的源码，本地编译运行。但多数人会选择那条732字节的捷径，因为快。

这种张力贯穿整个事件：AI让漏洞发现变快了，披露变快了，利用也变快了。但补丁链条的响应速度没有同比例提升。内核补丁已经存在，但流到各个发行版的稳定通道需要时间。Ubuntu、RHEL、Suse的更新节奏不同，容器镜像的重建和分发又有一层延迟。

对于跑Kubernetes集群的工程师，这意味着什么？你的节点操作系统可能还没补丁，但集群里跑着不可信的工作负载。传统的容器逃逸防护假设内核是可信边界，现在这个假设在本地用户场景下失效了。

AI辅助漏洞研究的拐点

Xint Code没有详细说明AI的具体用法，但语境很清楚：不是用AI生成攻击代码，而是用AI审计代码。这区分了两种AI安全应用——生成侧和发现侧。

发现侧的规模化正在改变漏洞经济学的平衡。传统模式下，安全研究员投入时间挖掘漏洞，选择负责任的披露或漏洞赏金，都是基于「发现成本高昂」的前提。如果AI把发现成本压到接近零，披露策略的激励结构就会重构。快速公开、制造压力、迫使厂商加速响应，可能变成更理性的选择——至少对发现者而言。

这不是说Xint Code做错了什么。他们的做法在伦理上有争议空间，但技术趋势是明确的：AI审计工具的普及，会让更多「沉睡的漏洞」被批量唤醒。Linux内核有3000万行代码，加密子系统只是其中一小块。类似的优化引入的缺陷，可能还藏在文件系统、网络栈、调度器的某个角落。

给你的行动清单

如果你是基础设施负责人，现在该做什么：

第一，确认你的内核版本和发行版补丁状态。不要假设「我上周刚更新过就安全」，这个漏洞的补丁窗口还在滚动。

第二，检查algif_aead的加载方式。运行lsmod看它在不在模块列表，或者查/proc/config.gz里的CONFIG_CRYPTO_USER_API_AEAD配置。编进内核核心的，必须走强制访问控制路线。

第三，评估AF_ALG套接字在你的环境中的真实用量。很多系统其实没在用内核加密服务，封掉无感知。如果确实在用，规划补丁窗口期的临时降级方案。

第四，重新审视容器和多用户场景的隔离假设。这个漏洞的利用前提是本地用户权限，但「本地」的定义在容器时代很模糊。sidecar、init容器、调试用的kubectl exec，都可能创造本地用户上下文。

最后，把AI辅助代码审计加入你的安全工具链。不是为了追赶时髦，而是因为攻击者已经在用了。防御侧的反应速度，必须匹配发现侧的加速。