你敢相信吗就在你以为服务器固若金汤的时候一个从2011年就悄悄躺进Linux内核的老毛病正等着任何一位本地用户伸手拿到root钥匙。更棘手的是在那些跑满Docker容器的云主机上这个编号为CVE-2025-39964的内核漏洞甚至能让攻击者穿透容器边界直接染指宿主机。美国网络安全与基础设施安全局CISA已经把它列入已知被利用漏洞目录——这意味着它不再只是实验室里的理论风险而是正在真实世界里被 weaponize 的武器。不起眼的加密接口成了提权的黄金通道问题的根源藏在Linux内核的AF_ALG用户空间加密接口里。这个接口本本分分地干着一件事让普通程序调用内核完成AES加密、解密这类计算密集型操作免去自己实现算法的麻烦。正因为面向非特权进程开放它长期以来都是内核安全研究者眼里的富矿——攻击面大、权限门槛低。STAR Labs的安全研究员Muhammad Alifa Ramdhan在为Google的kernelCTF项目审计内核代码时注意到了sendmsg()处理路径上的一处竞争条件。正常情况下内核会把一个或多个请求里的加密输入收集起来用分散-聚集列表scatter-gather list登记这些缓冲区一个名为merge的上下文标志则负责提示末尾缓冲区还有富余页面新数据可以安全地追加在后面。麻烦出在并发写入上。两个线程同时往同一个AF_ALG操作套接字写数据时虽然套接字锁能护住大部分状态变更可一旦某个线程因为要等缓冲区可写空间而被挂起这把锁就会被临时放掉。就在这片刻的空窗里另一个写入者已经动手改了共享上下文。按照IDNsec的复盘攻击者只要踩准时间差就能让ctx-merge在最终的scatter-gather列表里根本没有有效条目的情况下依然保持开启。这样一来后续的写入操作会越过预期数组去访问sg[-1]——也就是越界读取元数据。而被攻击者精心构造的堆数据恰好能伪装成散列列表元数据把一次越界访问滚雪球般地变成用户复制预言机最终推导出任意内核写入原语。有了任意写剩下的只是选择题。概念验证程序瞄准的是core_pattern——这个内核参数决定着Linux如何处理进程崩溃时的核心转储。当它以竖线字符开头时Linux会把指定的程序当作转储处理器来执行。覆盖这个值再故意让子进程崩溃一段攻击者控制的二进制代码便堂而皇之地以root身份运行起来。整个链条环环相扣从普通用户到root理论上可以在受影响的机器上稳定复现。容器不是保险箱共享内核的原罪很多运维同行容易陷入一个误区觉得把服务关进Docker容器就等于上了保险。可容器的安全模型本质上建立在命名空间和控制组的隔离之上大家共享的还是同一个宿主机内核。一旦拿到内核级的任意写原语namespace这层纸墙几乎形同虚设——攻击者在容器内部完成的提权动作落地时就是宿主机上的root权限。这正是CVE-2025-39964最让云厂商和多租户平台头疼的地方。在一个多用户容器编排环境里任何一个能执行不可信本地代码的租户都可能借这条路径逃逸出容器去读宿主机上的敏感文件、横向移动甚至控制整台宿主机。kernelCTF的参赛版本正是顺着这个思路完成了Docker容器逃逸的演示并因此拿下了113,337美元的奖金。对攻击者来说这是一本万利的买卖对防守方来说这是必须立刻堵上的口子。影响面有多大这个缺陷是随2011年发布的Linux 2.6.38进入内核代码树的一躺就是约14年。受影响的范围包括修复版本之前的各个稳定分支内核以及各大发行版自行移植维护的内核。官方公告中列出的修复版本涵盖Linux 5.10.246、5.15.195、6.1.155、6.6.109、6.12.50和6.16.10。换句话说过去十多年间部署的绝大多数生产环境只要没打上补丁理论上都暴露在风险之下。从威胁场景看几类系统应当被列为优先处置对象对外提供服务的共享Linux基础设施、运行着大量容器的宿主机、允许多用户登录的通用服务器以及任何可能执行不可信本地代码或租户工作负载的环境。CISA的KEV目录收录已经把尽快修复从建议变成了近乎强制的合规要求。修复方案与应急动作上游开发者给出的修复思路相当克制为AF_ALG上下文加上独占写权限。补丁引入了对ctx-write状态的检查第二个并发写入者会直接失败返回而不是去碰共享状态。这等于从根上掐断了竞争条件没有大动干戈地重构也把引入新问题的风险压到了最低。对管理员而言动作其实就三句话立刻安装发行版推送的已修补内核软件包安排窗口重启系统让新内核生效然后逐台核对容器主机和多用户系统是否全部覆盖。别指望热补丁或者下次维护窗口再说——CISA的名单已经证明有攻击者在现实中用它干活拖延的每一天都是敞开的窗口期。写在最后CVE-2025-39964给行业提了个醒内核里那些看似 innocuous 的老接口往往是审计盲区里最深的暗礁。一次并发写入的竞争条件能逐级放大成任意内核写再演变成提权与容器逃逸的完整杀伤链。对于依赖Linux支撑业务的团队来说这次事件至少留下两条经验——一是把内核补丁管理从定期维护升级为风险驱动的响应机制二是对共享内核的隔离模型保持清醒容器挡得住进程挡不住内核本身。如果你的服务器还在跑未修复版本的内核现在就去检查更新这个动作的价值胜过事后任何一份复盘报告。