Cloudflare 5月7日披露了其应对Linux内核本地提权漏洞“Copy Fail”（CVE-2026-31431）的细节。该漏洞于2026年4月29日公开，影响Linux kernel中algif_aead/authencesn路径，核心问题是一次4字节越界写。Cloudflare称，其安全和工程团队完成了暴露面评估、内部检测验证、公开前48小时日志回溯、eBPF临时缓解和修复内核滚动更新，未发现恶意利用，也未影响客户数据和服务。
这不是远程代码执行漏洞。攻击者需要先在目标机器上具备本地执行条件，才可能利用它提权。对云厂商和企业SRE团队来说，麻烦在于另一处：内核补丁通常意味着重启，而大规模基础设施不能像单台服务器那样“一重了之”。Cloudflare这次复盘的重点，正是如何在补丁完全落地前缩短风险窗口。
Copy Fail的危险在于“改了缓存里的root程序”
Copy Fail利用链默认瞄准/usr/bin/su这类setuid-root二进制。攻击者通过AF_ALG套接字调用内核加密API，再借助splice()把目标文件的page cache页接进加密操作的scatterlist。漏洞触发时，authencesn会在合法输出区域之后多写4个字节。
这4个字节看起来很小，但足够被反复用于污染page cache中的程序文本。由于setuid程序执行时带root权限，攻击者可以让被污染的/usr/bin/su加载恶意片段，从普通用户升到root。上游修复来自Linux内核提交a664bf3d603d，做法是回退2017年引入的in-place优化。
| 项目 | Copy Fail的实际含义 | 判断 |
|---|---|---|
| 漏洞类型 | 本地权限提升，不是远程入侵 | 风险高，但前置条件明确 |
| 关键入口 | AF_ALG、algif_aead、splice() | 适合做运行时拦截 |
| 默认目标 | /usr/bin/su等setuid-root二进制 | 云主机和多用户系统更敏感 |
| 修复难点 | 内核补丁通常要重启 | 真正考验运维节奏 |
Cloudflare的应对价值在补丁之外
Cloudflare称，漏洞公开后其既有行为检测在内部授权验证中数分钟内识别出利用模式，且不需要签名或规则更新。检测链路从脚本解释器、内核加密子系统到提权二进制，按行为异常而不是按CVE编号识别。这一点比“发了补丁”更值得企业安全团队参考，因为真实攻击往往发生在补丁窗口之前。
随后，Cloudflare回溯公开前48小时的集中日志，检查漏洞运行时会留下的内核日志痕迹，并审计访问记录、命令活动、系统二进制哈希、持久化机制和异常网络连接。其结论是没有发现恶意利用。这个说法只适用于Cloudflare自身环境，不能外推为行业范围内“没人被打”。
时间线上，4月29日16:00漏洞公开；当晚Cloudflare开始评估暴露面和缓解方案；22:52确认行为检测覆盖；4月30日凌晨3:14启动安全事件流程；当天下午部署AF_ALG可见性管道；当晚推出bpf-lsm缓解；5月4日起按正常和手动重启节奏部署修复内核。
不卸载模块，而是给AF_ALG加白名单
研究人员建议的直接缓解是禁用并卸载algif_aead模块。这在单机或小规模环境中简单有效，但Cloudflare认为会影响依赖内核加密API的软件。它最终选择用BPF Linux Security Module拦截socket_bind：不是AF_ALG就放行；是AF_ALG则检查调用二进制路径；只有已知合法程序在allow-list中才允许绑定。
这个取舍很有行业代表性。云厂商面对内核漏洞，常见路线有三种：立即停用相关功能、加临时运行时护栏、等待维护窗口补丁重启。停用最干净，也最容易误伤生产；等重启最稳，也留下窗口；bpf-lsm介于两者之间，代价是需要提前具备eBPF工程能力和全网可观测性。
Cloudflare还用prometheus-ebpf-exporter跟踪全网AF_ALG使用情况，确认已知内部服务是唯一合法用户后再启用拦截。这是原文里容易被忽略的限制：bpf-lsm不是一条复制即用的万能命令。没有资产画像、二进制路径基线和回滚机制，白名单本身也可能造成生产故障。
对企业内核运维和SRE团队，现实动作很清楚：确认所用LTS内核是否已包含修复；检查是否有本地多租户、CI runner、跳板机、共享开发机等高风险场景；评估能否监测AF_ALG绑定、setuid二进制哈希变化和异常提权链路。接下来更该观察的不是Cloudflare是否继续“无影响”，而是各发行版和云环境中，补丁重启窗口到底被拖了多久。