实际上，该问题允许低权限本地用户滥用此子系统内存处理路径中的逻辑缺陷，并将影响升级为完全的系统完整性破坏。kernel.org 发布并在 NVD 中反映的评分为 CVSS 7.8，向量为 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，意味着该攻击需要本地执行，但对机密性、完整性和可用性具有高影响。

引入和披露时间

• 可利用的根因于 2017 年引入内核，当时对 algif_aead 添加了就地优化。
• 该 CVE 于 2026 年 4 月 22 日 在 NVD 中发布。
• 该问题以 Copy Fail 名称及公开的概念验证代码于 2026 年 4 月 29 日 进行了更广泛的公开披露。
• 主要上游修复于 2026 年 4 月 1 日 提交，早于广泛的最终用户披露。

其利用的内容

根据已发布的技术公告，该缺陷依赖于以下因素的组合：

• 内核 AF_ALG 接口
• algif_aead 模块
• 2017 年引入的就地操作优化
• 将该接口与 splice() 链接

实际结果是，本地进程能够对可读文件的页缓存支持页面执行一次小型的受控写入。在有利条件下，这足以将有限的本地立足点转变为 root 权限提升。

这对公司的影响

真正的风险不仅仅是"运行易受攻击的 Linux 内核"，而是允许低信任度的本地代码访问此内核路径。在企业环境中，这通常意味着以下场景的暴露程度更高：

• 多用户服务器
• 跳板机和堡垒机
• CI/CD 运行器
• 运行不可信代码的容器化工作负载
• Kubernetes 集群
• 托管自动化、代理、插件或第三方作业的虚拟机

如果攻击者已经拥有某种形式的本地执行能力，即使没有 root 权限，此 CVE 也可能成为主机被攻陷的下一步。实际上，这扩大了以下风险：

• 完全接管服务器
• 修改本地二进制文件或工件
• 窃取凭据、令牌和驻留机密
• 向其他资产进行横向移动
• 破坏流水线和构建链

algif_aead 模块的用途

algif_aead 是内核用户空间加密接口（AF_ALG）的一部分。它允许应用程序通过套接字使用内核加密原语，尤其是 AEAD 操作（带关联数据的认证加密）。

对于大多数标准服务器工作负载，此模块通常不是必需的。根据 CERT-EU 发布的缓解指南，禁用 algif_aead 作为临时缓解措施：

• 不应影响 dm-crypt 或 LUKS
• 不应影响 kTLS
• 不应影响 IPsec/XFRM
• 不应影响标准使用中的 OpenSSL、GnuTLS、NSS 或 SSH

另一方面，禁用它可能会影响：

• 明确配置为使用 afalg 引擎的应用程序
• 直接打开 AF_ALG 套接字的软件
• 通过内核加密 API 使用 aead、skcipher 或 hash 的自定义集成

换句话说，对于大多数企业主机，阻止该模块的影响往往较低。在设备、自定义加密栈或高度优化的软件路径中，应在部署前验证影响。

禁用模块的运营影响

阻止该模块可立即降低暴露程度，但也带来权衡：

• 依赖 AF_ALG 的应用程序可能无法启动或失去内核支持的加密加速
• 自定义工作负载可能仅在运行时失败，而非启动时
• 如果模块已加载，缓解措施仅在成功卸载或重启后才算完成

对于生产环境，更安全的方法是在受控维护窗口内应用缓解措施，并在之后验证关键应用程序。

推荐的永久修复

将模块加入黑名单仅是临时缓解措施。永久修复是：

1. 安装由发行版供应商提供的已修补内核
2. 重启主机，以便实际加载新内核
3. 验证主机不再被报告为受影响
4. 然后才决定模块黑名单是否应保留

其他推荐措施：

• 优先修补具有本地用户、容器或不可信代码执行的主机
• 在适用的情况下，在容器和流水线中使用 seccomp 限制 AF_ALG 套接字创建
• 审查明确使用 afalg 或内核加密 API 的位置
• 维护内核版本和待重启主机的清单
• 将 CI/CD 运行器和 Kubernetes 节点视为高优先级

脚本检查的内容

脚本检查：

• 主机主机名
• 当前运行的内核版本
• 通过 /etc/os-release 获取的操作系统
• algif_aead 模块是否存在
• 模块当前是否已加载
• 模块是否被 modprobe 规则阻止
• 主机是否需要重启（/var/run/reboot-required）
• 在可用时，通过 pro fix CVE-2026-31431 --dry-run 报告的 Ubuntu Pro 状态

基于此，它返回以下分类之一：

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

分类逻辑

总结：

• 如果 Ubuntu 工具指示主机不受影响或已修复，则状态变为 PATCHED_OR_NOT_AFFECTED。
• 如果当前内核中不存在 algif_aead 模块，则状态倾向于 LIKELY_NOT_VULNERABLE。
• 如果模块存在但已被阻止且未加载，则状态变为 MITIGATED。
• 如果 Ubuntu 指示主机受影响且模块已加载，则状态变为 VULNERABLE_MODULE_LOADED。
• 如果模块存在且可加载，但无法确认补丁状态，则状态变为 POTENTIALLY_VULNERABLE。

要求

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get（用于 --update）
• 以非 root 用户运行时需要 sudo
• 可选 pro，用于丰富 Ubuntu 上的分析

用法

如果脚本文件名为 check_cve_2026_31431.sh：

默认检查

示例输出：

JSON 输出

示例：

此输出适用于自动化、资产清单和合规流水线。

缓解措施

--mitigate 模式创建文件：

内容如下：

之后，脚本尝试使用以下命令从内存中移除模块：

用法：

如果用户不是 root，脚本将尝试使用 sudo。

更新

--update 模式运行：

用法：

此模式尝试在基于 Debian 和 Ubuntu 的系统上升级内核相关软件包。在其他环境中，此步骤可能不适用。

帮助

输出：

重要限制

• 脚本使用启发式方法。它不证明可利用性；它仅评估暴露程度和缓解状态。
• ubuntu_affected 和 fix_available 字段依赖于 pro 命令的存在。
• --update 步骤使用面向 Ubuntu 和 Debian 的软件包模式，可能无法覆盖所有自定义内核。
• 在某些发行版上，模块可能存在且行为与脚本预期不同。
• 在某些环境中，阻止模块可能需要重启才能保证一致的状态。

推荐工作流程

1. 运行 --check 评估主机。
2. 如果模块可用且未应用补丁，则运行 --mitigate。
3. 运行 --update 或应用官方供应商更新。
4. 如有必要，重启主机。
5. 运行 --check --json 验证最终状态并保留证据。

备注

为便于发布清晰，脚本理想情况下应使用描述性名称，例如：

致谢

材料整理并发布，致谢 SEC17。

官方网站：

• https://sec17.com