CVE-2026-31431 复盘：补丁发布了不等于安全了，容器逃逸的风险窗口在“到达”之前

今年 4 月 CNVD 收录了一个 Linux 内核本地权限提升漏洞 CVE-2026-31431，评级高危，且已发现在野利用。漏洞的根源在加密子系统：本地普通权限用户可组合 AF_ALG 套接字和 splice 系统调用，向可读文件或 SUID 程序的页缓存中写入数据，篡改高权限进程，最终提权到 root。这个漏洞对云服务器和多租户环境尤其敏感——容器与宿主机共享内核，容器内提权即等价于宿主机 root，隔离边界不在容器层，而在内核层。我们花了一周做应急和加固，把处置链路和踩过的坑记录下来。

一、 第一个认知纠正：“我用的发行版受支持，所以没问题”是错的

漏洞披露后，很多团队的直觉是“等云厂商镜像更新”。但这次的时间线暴露了一个更本质的问题：上游内核早已修复，但发行版的补丁不一定已经到达你的机器。Ubuntu 26.04、24.04 和 22.04 在漏洞公开后的一段时间内仍未收到修复，而这三个版本恰恰是公有云上最常见的镜像基础。依赖“长期支持版本”作为安全结论，在这次会得到错误的达标判断。

正确的排查口径是内核包的实际版本，而不是发行版版本号。逐台或按镜像基线核对 uname -r 和内核包版本与上游修复 commit 的对应关系，而不是看控制台上“系统已是最新”的提示。

bash
uname -r
rpm -qa | grep kernel   # 或 dpkg -l | grep linux-image
二、 临时缓解：在补丁到达之前，先把攻击面收窄

官方补丁可用之前，CNVD 给出的临时措施是禁用 algif_aead 内核模块，以及通过 seccomp 阻断容器内 AF_ALG socket 创建。我们两边都做了：

宿主机层面，直接 blacklist 模块并确保它不在启动时自动加载：

bash
echo "blacklist algif_aead" > /etc/modprobe.d/disable-algif-aead.conf
modprobe -r algif_aead 2>/dev/null
容器层面，在 Pod 的 seccomp 配置中拒绝 socket 系统调用携带 AF_ALG 域。对于运行不可信或多租户工作负载的节点，如果短期无法打内核补丁，架构层面的强隔离（微型虚拟机等）是少数真正有效的缓解手段。

三、 行为侧观测：补丁之外的第二道防线

这个漏洞的利用链在容器内最终会表现为对宿主机路径的异常访问、异常的内核接口调用、以及非预期的 namespace 或 capability 变化。我们在 HSS 和审计日志中补充了针对容器进程访问 /proc、/sys 敏感路径以及异常 AF_ALG 相关系统调用的告警规则。这类行为在单一控制台上未必判为高危，但放在容器逃逸的链路上看，是攻击者必须经过的步骤。

四、 总结

CVE-2026-31431 的处置链路可以归纳为：核对内核包实际版本 → 禁用 algif_aead 模块 → seccomp 阻断容器内 AF_ALG 创建 → 对高敏感负载评估强隔离 → 补行为侧观测。最深的教训不是某个模块的代码缺陷，而是“补丁存在”和“补丁抵达”之间的窗口，往往就是风险最大的窗口。把镜像流水线也纳入内核包版本的追踪，才能在下一次类似漏洞出现时，不被“受支持的发行版”这个标签误导。