它不是远程一键打穿服务器的漏洞，但一旦攻击者已经拿到低权限执行入口，Copy Fail 就可能把后半段攻击链变得很短。
Linux 内核漏洞里，最容易被误判的一类就是本地权限提升。很多人看到“Local Privilege Escalation”会先松一口气：既然不是远程代码执行，是不是优先级可以往后排？放在单用户桌面环境里，这种判断有时还说得过去。但放到服务器、CI Runner、Kubernetes 节点、多租户主机、在线开发环境和共享计算平台里，本地提权往往不是孤立漏洞，而是攻击链中最关键的那一跳。
CVE-2026-31431，代号 Copy Fail，就是这样一个漏洞。
它影响 Linux Kernel 加密子系统，核心涉及 authencesn、algif_aead、AF_ALG 用户态加密接口以及 splice() 系统调用。漏洞被评为 CVSS 3.1 7.8 High，向量为 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H。这组评分其实已经说明了它的基本性质：攻击者需要本地低权限，但利用复杂度低，不需要用户交互，一旦成功可能影响机密性、完整性和可用性。
真正让它受关注的地方不只是评分，而是公开描述中的几个关键词：可以向任意可读文件的页缓存写入受控的 4 字节数据、可通过影响 setuid 二进制文件的执行语义获得 root 权限、PoC 已公开、传统文件系统事件监控可能看不到。对于已经习惯把“升级容器镜像”当作主要修复动作的云原生团队来说，这个漏洞还提醒了一件老问题：容器共享宿主机内核，内核本地提权从来不是容器内部的小事。
下面这篇文章不复述 PoC，也不提供可直接用于攻击的复现步骤。重点放在防御方真正需要判断的几个问题：Copy Fail 到底是什么、它为什么危险、哪些系统需要优先处理、临时缓解怎么做、检测应该看哪里，以及厂商风险评级为什么会出现差异。
Copy Fail 是什么：一个发生在内核加密路径上的本地提权漏洞
CVE-2026-31431 属于 Linux Kernel 本地权限提升漏洞。它不是一个开放端口就能远程触发的问题，攻击者必须已经能在目标机器上以低权限身份执行代码。这个前提很重要，因为它决定了漏洞的第一层风险边界。
但在现实环境里，“低权限代码执行”并不罕见。一个 Web RCE、泄露的 SSH 普通账号、被污染的 CI 任务、恶意依赖包、容器内 shell、Jupyter Notebook、在线 Judge、托管开发环境，都可能提供这样的 foothold。Copy Fail 的危险性就在于，它可能把这些低权限入口进一步放大成 root 权限。
这个漏洞的关键组件集中在 Linux 内核加密子系统：
AF_ALG：Linux 提供给用户态访问内核加密 API 的 socket 接口；algif_aead：与 AEAD 加密算法接口相关的内核路径；authencesn：与认证加密和 IPsec ESN 处理相关的加密模板；splice()：允许数据在文件描述符之间移动，减少用户态和内核态之间的数据拷贝。
单独看这些组件，都有正常用途。AF_ALG 是用户态调用内核加密能力的接口，splice() 是性能优化常见工具，algif_aead 的 in-place 操作也是出于减少拷贝、提升效率的工程取舍。Copy Fail 的问题在于，这些机制组合在一起后，某些页缓存页面被放进了不该可写的路径里，而 authencesn 的处理逻辑又提供了一个受控的 4 字节写入点。
这不是“攻击者直接打开系统文件并写入磁盘”那么简单。更准确地说，它影响的是页缓存。内核执行二进制文件时会从页缓存读取内容，如果攻击者能修改某个 setuid root 程序在页缓存中的内容，即使磁盘文件本身没有被传统意义上写坏，执行语义也可能被改变。setuid 程序本来就会以文件属主权限运行；如果目标是 root 拥有的 setuid 二进制，攻击者就有机会借此获得 root 权限。
这也是 Copy Fail 和 Dirty COW、Dirty Pipe 常被放在一起比较的原因。它们都不是简单的文件权限绕过，而是利用 Linux 内核内存、页缓存或写入语义中的边界问题，让“只读”或“可信”的内容在执行层面变得不再可信。
“改页缓存”比“改文件”更麻烦
理解 Copy Fail，最好先把“磁盘文件”和“页缓存”分开看。
Linux 为了性能，不会每次读文件都直接访问磁盘。文件内容会被缓存到内存里的页缓存中。后续读取、执行二进制文件时，很多路径读到的其实是缓存页。正常情况下，页缓存由内核严格维护，用户不能绕过文件权限去修改只读文件对应的缓存内容。
Copy Fail 的问题就在这里：它不是走普通写文件路径，而是通过 AF_ALG、splice() 和 algif_aead 的组合，让本不该进入可写输出路径的页缓存页面参与了内核加密操作的数据流，再借助 authencesn 中特定处理行为产生受控写入。
这带来两个防御上的麻烦。
第一个麻烦是，很多文件完整性监控工具关注的是文件系统事件。比如文件被打开写入、权限变化、内容落盘修改，这类事件通常可以被 inotify、审计规则或传统 FIM 产品捕捉。但页缓存层面的短暂篡改不一定触发这些事件。换句话说，文件路径没变、磁盘内容没变、mtime 也可能没有明显异常，执行结果却已经被影响。
第二个麻烦是，它针对的是 Linux 执行路径中的信任基础。setuid 程序原本是系统允许低权限用户触发高权限操作的一种机制，例如 passwd 这类程序需要在受控逻辑下修改敏感文件。安全模型假设这些二进制本身可信、不可被低权限用户修改。一旦攻击者能在页缓存层面改变二进制执行内容，这个假设就被绕开了。
需要克制地说，页缓存篡改并不等同于磁盘文件被永久改写。某些通告中出现“持久化提权”这类表述，容易让人误解成漏洞本身直接把磁盘上的系统文件永久改坏。更稳妥的理解是：Copy Fail 提供了运行时影响可信文件执行语义的能力；攻击者是否进一步建立持久化，取决于后续攻击链，而不是页缓存写入本身天然等于永久落盘。
漏洞链条：几个正常机制怎样组合成越权写入
从防御视角看，不需要逐行理解 PoC，也应该理解 Copy Fail 的高层链路。它大致可以拆成四步。
第一步，algif_aead 曾经引入过 in-place 操作优化。这个优化对应的历史 commit 被 CVE 记录标为引入点：72548b093ee38a6d4f2a19e6ef1948ae05c181f7。in-place 的意思是尽量在原位置处理输入和输出，减少额外缓冲区和数据拷贝。性能上这很合理，但安全问题常常出现在“同一块数据到底什么时候可以被当作输入、什么时候又被当作输出”这种边界里。
第二步，splice() 可以把文件相关页面接入数据流。它的设计目标是减少拷贝，让数据在内核内部更高效地移动。如果某个可读文件的页缓存页被接进后续 crypto socket 处理路径，而这条路径又错误地把它放到了可写 scatterlist 里，风险就出现了。
第三步，authencesn 在处理认证数据时存在 4 字节写入行为。公开通告里提到，这与 IPsec ESN 相关认证数据中的序列号字节重排有关。在特定缓冲区布局下，这个写入可能越过接收缓冲区边界，覆盖后续链入的页缓存页面。
第四步，攻击者选择有提权价值的目标文件。公开描述中最典型的是 setuid 二进制。攻击者不需要把整个文件改写，只要能够控制关键位置的少量字节，就可能改变执行路径。Copy Fail 的公开说法强调写入规模是 4 字节，这看起来很小，但对二进制补丁、跳转、指令语义或校验路径而言，少量字节有时已经足够危险。
修复方向也能反过来说明根因：Linux 相关补丁标题指向 crypto: algif_aead - Revert to operating out-of-place，也就是回退 algif_aead 的 in-place 操作逻辑，改回 out-of-place 处理。这样做牺牲了一部分原本想要优化的路径，但把输入页和输出页重新隔离开，避免页缓存页进入可写目标 scatterlist。
这类漏洞最值得反思的地方在于，它不是一个“明显愚蠢”的错误。它更像长期复杂系统里常见的安全债：多个子系统各自合理，组合后却破坏了权限边界。内核优化、零拷贝、用户态 crypto 接口、页缓存、setuid 执行模型，每一层都有历史包袱和性能诉求，漏洞就藏在交界处。
影响范围：不要只看“发行版名字”，要看内核线、补丁和配置
Copy Fail 的影响范围很容易被媒体标题写得过宽，比如“几乎所有 2017 年以来 Linux 发行版”。这种说法能表达严重性，但不适合生产排查。企业真正要判断的是：当前运行内核是否包含引入 commit、是否已经包含修复 commit、发行版是否做了 backport、相关内核配置和模块是否启用。
CVE 记录给出的判断方式以 commit 和版本线为核心：
引入点：
72548b093ee38a6d4f2a19e6ef1948ae05c181f7；修复 commit 包括：
fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8ce42ee423e58dffa5ec03524054c9d8bfd4f6237a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
6.18.22、6.19.12、7.0被列为不受影响或已修复版本线。
一些安全通告列出了已知受影响发行版，包括 Ubuntu 24.04 LTS、Amazon Linux 2023、Red Hat Enterprise Linux 10、Red Hat Enterprise Linux 9、Red Hat Enterprise Linux 8、SUSE 16。Theori 公开仓库 README 中还列出过若干测试环境，例如 Ubuntu 24.04 LTS 的 6.17.0-1007-aws、Amazon Linux 2023 的 6.18.8-9.213.amzn2023、SUSE 16 的 6.12.0-160000.9-default 等。
这里有一个容易踩坑的点：发行版内核版本号不总是等于上游主线版本状态。企业发行版经常 backport 安全补丁，版本号看起来旧，但可能已经修了；也可能版本号处于某条受影响内核线，但发行版补丁还没跟上。因此，排查时不能只用“uname 看到某个数字”就下结论，最好结合发行版安全公告、内核包 changelog、修复 commit 状态和实际配置。
基础排查可以从几件事开始：
BASH
uname -r
用于确认当前运行内核版本。注意，安装了新内核包但没重启时，uname -r 仍然显示旧内核。
BASH
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
用于查看用户态 AEAD crypto API 相关配置是否启用。
BASH
lsmod | grep algif
用于确认相关 algif 模块是否已加载。
这些命令只能帮助缩小范围，不能替代厂商公告和补丁核验。尤其在云主机和托管 Kubernetes 环境中，还要确认宿主机节点实际运行的内核，而不是只看容器镜像里的用户态版本。
为什么厂商评分会不一致
Copy Fail 的 CVSS 评分是 7.8 High，但不同厂商给出的优先级并不完全一致。Ubuntu 页面里 CVSS 是 High，Ubuntu priority 标为 Medium；Red Hat Bugzilla 中 severity 也显示 medium；腾讯云、奇安信等通告则按高风险或高危处理。
这并不一定互相矛盾。CVSS 描述的是漏洞在通用模型下的技术严重性，而厂商 priority 往往会结合发行版默认配置、可利用前提、是否远程、补丁发布节奏、已有缓解方式等因素。Copy Fail 需要本地低权限执行，这是它没有被打到远程满分的主要原因。
但对企业来说，只看“Medium”容易低估实际风险。更合理的判断方式是按资产场景分层：
单用户桌面、无不可信本地代码执行：风险相对较低，但仍应随系统更新修复；
普通互联网服务器：如果已有 Web 应用暴露面、运维账号较多，应提高优先级；
CI/CD Runner：高优先级，因为 Runner 天然执行大量外部或半可信代码；
多租户 Linux 主机：高优先级，因为本地低权限用户就是常态；
Kubernetes 节点和共享内核容器环境：高优先级，因为容器边界依赖内核；
在线开发环境、Notebook、科研计算平台、共享 GPU 训练集群：高优先级，因为用户代码执行频繁且权限隔离依赖系统层。
简单说，Copy Fail 的风险不是平均分布在所有 Linux 机器上。它在“允许别人运行代码”的机器上最危险。
容器场景：问题不在镜像里，而在共享内核
很多云原生团队处理漏洞的第一反应是重构镜像、升级基础镜像、重新部署 Pod。对用户态库漏洞，这通常有效。但 Copy Fail 是内核漏洞，修复位置在宿主机内核。容器镜像升级本身不能修掉宿主机内核里的 algif_aead 问题。
容器隔离不是虚拟机隔离。大多数容器共享宿主机内核，只是在命名空间、cgroup、能力集、seccomp、LSM 等机制下限制进程看到和能做的事情。如果攻击者在容器内获得代码执行，并且容器策略允许触发相关内核接口，那么内核 LPE 就可能成为容器逃逸原语。
这并不意味着所有容器环境都会被 Copy Fail 自动打穿。实际可利用性取决于宿主机内核版本、配置、模块、seccomp 策略、容器能力、文件可见性、挂载方式等。但防御策略应该以宿主机为中心：
升级 Kubernetes 节点内核，而不是只升级业务镜像；
对节点做滚动升级，确保新内核安装后完成重启；
将运行不可信代码的工作负载调度到隔离节点池；
对 CI Runner、构建服务、在线代码执行服务单独划分节点；
使用 seccomp 限制不必要的 socket family，尤其是 AF_ALG；
配合 AppArmor、SELinux、无特权容器、只读根文件系统、最小 capability 策略降低利用空间。
腾讯云通告中提到，容器环境可以通过 seccomp 禁止创建 AF_ALG socket，AF_ALG 的 family 编号为 38。这类策略不能代替内核补丁，但在补丁窗口期有实际价值。
修复策略：升级内核优先，禁用 algif_aead 只是过渡
处理 Copy Fail，最可靠的动作是升级到发行版提供的安全内核，并重启进入修复后的内核。只安装内核包不重启，运行态仍然暴露。对生产集群来说，真正的修复动作包括：确认补丁包可用、分批安装、迁移工作负载、重启节点、验证运行内核版本。
安全版本方面，CVE 记录和安全通告中提到的关键版本线包括：
内核线 | 建议状态 |
|---|---|
6.18 | 升级至 6.18.22 或更高修复版本 |
6.19 | 升级至 6.19.12 或更高修复版本 |
7.0 | 被列为不受影响或已修复版本线 |
旧版本或发行版内核 | 以厂商安全内核和 backport 补丁为准 |
无法立刻升级时，可以考虑禁用 algif_aead 模块作为临时缓解。常见做法是阻止模块加载，并卸载已加载模块：
BASH
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
lsmod | grep algif_aead
这组操作的含义是：通过 modprobe 配置让 algif_aead 后续加载失败，再尝试卸载当前已加载模块，最后检查模块是否仍存在。它适合作为补丁前降低风险的措施，不应被当成最终修复。
禁用 algif_aead 也不是完全零成本。大多数通用服务器可能没有显式依赖这个接口，但少数场景可能会受影响，例如显式使用 AF_ALG 的用户态加密程序、OpenSSL 特定 afalg engine 配置、嵌入式设备上的加密卸载路径、直接绑定 aead/skcipher/hash socket 的自研应用。上线前最好先在测试环境验证关键业务。
如果处在 Kubernetes 或容器平台，临时缓解还可以加入 seccomp 层面限制。防御思路不是“让容器里没有漏洞”，而是让容器进程无法触达触发漏洞所需的内核接口。
检测策略：不要只盯文件变更，要看行为链
Copy Fail 的检测难点在于页缓存层面的修改不一定留下传统文件变更痕迹。仅靠 inotify 或文件完整性监控，很可能无法覆盖这种攻击路径。防御方需要把检测重点前移和外移。
比较实用的监控方向包括：
异常创建 AF_ALG socket；
低权限用户进程异常调用
splice()并与 crypto socket 组合；普通用户频繁执行 setuid 二进制；
CI Runner 中出现与构建任务无关的内核接口调用；
容器内进程尝试访问不常见 socket family；
Web 服务用户、构建用户、Notebook 用户触发异常权限变化；
setuid 程序执行行为偏离基线。
auditd、eBPF、EDR、Falco 一类运行时安全工具都可以围绕这些行为设计规则。这里的关键不是记录每一次正常系统调用，而是建立上下文：哪个用户、哪个容器、哪个工作负载、哪个进程树、在什么时间调用了不常用内核接口。
资产排查也应优先从高风险机器开始：
暴露公网服务且历史上出现过 WebShell 或弱口令风险的主机；
自托管 GitLab Runner、GitHub Actions Runner、Jenkins agent；
运行第三方代码的构建服务器；
Kubernetes worker 节点；
多用户 SSH 登录服务器；
在线 IDE、JupyterHub、在线 Judge、沙箱平台；
共享 GPU/AI 训练平台；
高权限但补丁窗口长的数据库、中间件和基础设施节点。
一个现实建议是：不要把 Copy Fail 当成单点漏洞处理，而要顺手检查“低权限入口”。如果 Web 服务用户已经能执行任意命令，LPE 只是时间问题；即使今天修掉 Copy Fail，明天也可能换成另一个内核或用户态提权漏洞。
公开 PoC 的意义：不是恐慌信号，但补丁窗口已经变短
Theori 的 GitHub 仓库 theori-io/copy-fail-CVE-2026-31431 已公开，仓库包含 README.md 和 copy_fail_exp.py。抓取时显示 28 stars、7 forks、2 watching、1 issue、0 PR，没有 Release，也没有包分发，License 在抓取内容中未确认。
这类仓库不是常规开源项目，更像漏洞披露和 PoC 展示。它没有稳定版本、没有部署文档、没有长期维护承诺，也不应被防御方当成生产检测工具。它的真正意义是：利用门槛下降已经发生了。
PoC 公开不等于已经大规模在野利用。奇安信通告中提到暂未发现野利用，这是一个重要边界。防御团队不需要因为社交媒体标题陷入恐慌，也不应该把“未发现”理解成“不会发生”。PoC 一旦公开，攻击者把它改造成后渗透模块的成本会显著降低，尤其是在已经有低权限 foothold 的场景里。
对企业来说，合理动作是压缩补丁窗口，而不是等待确认攻击样本。内核本地提权漏洞的处置经常卡在重启窗口、业务连续性、节点迁移和兼容性验证上。Copy Fail 这种已有公开利用能力的漏洞，最怕的就是“补丁已安装但半年没重启”。
AI 辅助漏洞挖掘：不要神化，但攻防节奏确实变快了
Copy Fail 的传播中还有一个容易引起讨论的点：Theori 研究员 Taeyang Lee 被报道借助 Xint Code 识别攻击面并定位问题，Bugcrowd 和中文媒体都提到过 AI 安全审计工具在较短时间内辅助发现漏洞。
这件事不宜被写成“AI 自动发现了一个内核大洞”。内核漏洞挖掘仍然需要研究员理解子系统语义、判断可利用性、构造触发路径、确认影响范围和协调披露。AI 工具更像是放大器：帮助在庞大代码库里筛选可疑路径，减少人工初筛成本。
但对防御方来说，它的信号意义很明确：复杂开源基础设施中的历史优化代码，正在被更高效率地重新审视。过去某些隐藏多年的逻辑缺陷，因为搜索空间太大、组合路径太复杂，不容易被系统性发现。AI 辅助审计、语义搜索、代码路径分析成熟后，类似漏洞被挖出的频率可能会上升。
这会压缩两个窗口：漏洞从修复 commit 到被逆向理解的窗口，以及从 PoC 公开到被武器化的窗口。企业补丁管理如果还依赖人工临时响应，很难跟上节奏。
和 Dirty COW、Dirty Pipe 相比，Copy Fail 的特殊点在哪里
Copy Fail 常被拿来和 Dirty COW、Dirty Pipe 对比。这个类比有帮助，但也容易造成误解。
Dirty COW 的核心是 Copy-on-Write 竞争条件，攻击者通过竞争破坏私有只读映射，最终影响本不该可写的内容。Dirty Pipe 则围绕 pipe buffer 标志处理缺陷，使攻击者可以向页缓存写入数据。Copy Fail 同样触及页缓存和执行语义，但入口不在 COW 或 pipe buffer 标志，而在 crypto/AF_ALG/authencesn 这条路径。
公开说法中，Copy Fail 的一个特点是“不需要竞争条件”。如果这个描述在实际环境中成立，它会比很多 race 型 LPE 更稳定，因为攻击者不必依赖时序碰撞。另一个特点是攻击路径不依赖特定内核偏移，这也降低了跨发行版适配成本。
不过，类比历史漏洞时要保持边界。Dirty COW 和 Dirty Pipe 的影响范围、利用条件、修复路径都不同。Copy Fail 是否在某个环境可利用，仍要看具体内核、补丁、配置、模块、容器限制和目标文件可见性。把它简单写成“新 Dirty COW”能让读者迅速理解严重性，但不能替代资产级排查。
企业处置优先级：先修会执行不可信代码的机器
如果资源有限，不可能在一天内重启所有 Linux 主机，优先级应该贴着攻击路径排。
第一批应处理执行不可信或半可信代码的系统。CI Runner、构建机、在线评测、JupyterHub、开发沙箱、共享 GPU 训练节点，都属于这类。攻击者不需要先突破复杂边界，只要能让平台执行代码，LPE 就有用武之地。
第二批是多租户和共享登录环境。高校、科研机构、托管 Shell、堡垒机周边工具、运维跳板环境，都应提高优先级。本地用户越多，本地提权越危险。
第三批是 Kubernetes worker 节点和容器宿主机。尤其是混部了不可信工作负载与敏感业务的节点，应该尽快滚动升级，并把节点池隔离作为长期治理动作。
第四批是普通服务器。公网 Web 服务、数据库、中间件、内部服务虽然未必允许普通用户登录，但一旦前端应用被打成低权限 shell，Copy Fail 就可能成为后续提权路径。对历史上已经出现过入侵痕迹或暴露面较大的机器，应提前处理。
桌面和个人开发机也不应忽略，只是优先级可以结合是否运行不可信代码、是否多人共享、是否保存敏感凭证来判断。
这次漏洞真正提醒了什么
Copy Fail 不应该被理解成一个孤立的“732 字节脚本秒 root”故事。那种标题能制造传播，但对防御帮助有限。
它真正提醒的是三件事。
第一，Linux 内核中的性能优化会带来长期安全债。in-place、zero-copy、splice、页缓存复用，这些机制提升了性能，也增加了跨子系统组合复杂度。一个 2017 年引入的优化，可能多年后才以安全漏洞形式暴露。
第二，容器安全边界仍然离不开宿主机内核。镜像扫描、依赖升级、SBOM 都很重要，但遇到内核 LPE，最终还是要回到节点内核补丁、重启、seccomp、LSM、节点隔离这些基础工作。
第三，检测不能只盯文件落盘。页缓存、内核接口调用、setuid 执行行为、低权限用户异常进程树，都会成为现代 LPE 攻击链的一部分。传统 FIM 和 inotify 不是没用，而是不够。
对大多数团队来说，最务实的路线很简单：先确认内核是否受影响，尽快升级并重启；无法立即升级时禁用 algif_aead 或限制 AF_ALG；对 CI、容器、多租户主机优先处理；检测上关注异常 AF_ALG socket、splice() 组合行为和 setuid 执行；后续把内核补丁管理和节点滚动重启做成常规能力。
Copy Fail 不是远程无条件 root，也没有可靠证据表明已经大规模在野利用。但公开 PoC 已经把攻防节奏推到了补丁窗口期。对防御方来说，这已经足够构成行动理由。
参考资料
