文章总结： 文档分析Linux内核CVE-2026-31431（CopyFail）本地提权漏洞，该漏洞存在于AFALG加密子系统，允许低权限用户通过732字节Python脚本稳定获取root权限。漏洞原理涉及in-place操作与splice()结合时对只读页缓存的4字节写入缺陷，无需竞态条件且影响2017年后所有Linux内核版本。提供漏洞复现步骤、官方补丁（改用out-of-place模式）及临时缓解方案（禁用algifaead模块/Seccomp限制），建议管理员立即更新内核或部署安全防护。 综合评分： 85 文章分类： 漏洞分析,Linux安全,应急响应,解决方案,漏洞预警
732字节Python脚本通杀所有Linux
原创
Faithtiann Faithtiann
SEVENTEENSEC
2026年5月1日 20:20 上海
在小说阅读器读本章
去阅读
点击蓝字 关注我们
SEVENTEENSEC
声明
⊙本文作者：Faithtiann
⊙本文字数：2051
⊙阅读时长：约10分钟
注：本文仅供安全研究与学习之用，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，由使用者承担全部法律及连带责任，作者及发布者不承担任何法律及连带责任
前言
CVE-2026-31431（Copy Fail）是 Linux 内核中一个极为严重的本地提权漏洞。该漏洞潜伏在内核加密子系统中长达 9 年（自 2017 年内核版本 4.2 引入），允许拥有低权限的本地用户通过一段仅约 732 字节的 Python 脚本，稳定、无需竞态条件地获取系统的 root 权限。
漏洞原理
一、涉及的内核组件
AF_ALG 用户态接口
AF_ALG是 Linux 内核提供的一种 socket 地址族，允许用户态程序直接调用内核空间实现的加密算法。其设计初衷是避免用户态与内核态之间的数据拷贝，提升加密操作的性能。
AEAD (Authenticated Encryption with Associated Data)
algif_aead是 AF_ALG 的 AEAD 加密接口实现。AEAD 是一种同时提供机密性（加密）和完整性（认证）的加密模式，典型代表如 AES-GCM、ChaCha20-Poly1305。
authencesn 模板
crypto/authencesn.c是内核中用于 IPsec 的认证加密模板，在标准的 AEAD 基础上增加了对扩展序列号（Extended Sequence Number）的处理。
二、系统调用
splice()是 Linux 内核提供的一种“零拷贝”数据传输机制，允许在两个文件描述符之间直接移动数据，而无需将数据拷贝到用户态缓冲区。当 splice()用于将文件数据导入内核时，它会将文件的“页缓存”（Page Cache）页面直接映射到内核的散射表（scatterlist）中。页缓存是 Linux 用于加速文件 I/O 的内存缓存机制——文件内容被加载到内存后，后续的读取可以直接从内存中进行。
关键特性：
-
页缓存页面通常被标记为“只读”（对于只读映射）
-
磁盘上的文件内容不会被修改
-
进程重启后，页缓存会被重新从磁盘加载
三、漏洞核心：In-place 操作的逻辑缺陷
漏洞的根源在于algif_aead模块中 “In-place”操作与 “Out-of-place ”操作的处理逻辑错误。
In-place ：同一内存区域（源缓冲区） | 同一内存区域 （目标缓冲区）| 读写同一块内存，节省内存但需特殊处理
Out-of-place ：独立缓冲区（源缓冲区） | 独立缓冲区 （目标缓冲区）| 源和目标分离，更安全但消耗更多内存
在 2017 年（内核版本 4.2），内核引入了一项代码优化：在 algif_aead中默认使用 “In-place” 操作，即源缓冲区和目标缓冲区指向同一块内存。这项优化在大多数场景下工作正常，但在与 authencesn模块和 splice()结合使用时，暴露出严重的逻辑缺陷。
四、具体代码逻辑分析
在 “crypto/authencesn.c”的解密路径中：
-
攻击者通过 splice()将目标文件（如 /usr/bin/sudo）的页缓存映射到 AF_ALG 接口的输入端。此时，这些页缓存页面在源 scatterlist 中，理论上应为“只读”。
-
algif_aead因为使用了 in-place 操作模式，将源 scatterlist 同时作为目标 scatterlist 传入 authencesn的处理函数。
3.（漏洞点）authencesn在处理认证序列号时，需要在特定位置写入扩展序列号数据。但由于 in-place 模式下的逻辑缺陷，authencesn没有正确区分“只读源”和“可写目标”，而是直接将数据写入了页缓存页面。
- 最终实现对任意可读文件页缓存的 “4 字节确定性写入”。
这是漏洞的核心利用原理。
Copy Fail 的独特危险在于：它不需要竞态条件，是确定性的逻辑错误。这意味着每次触发都会成功，极大地提高了攻击的可靠性。
漏洞复现
安全提示：复现实验请在隔离的虚拟机环境中进行，切勿在生产系统上操作。
实验环境
ubuntu虚拟机
poc: https://github.com/theori-io/copy-fail-CVE-2026-31431
检查内核版本（2017年以后的内核均受影响）
uname -r
cat /etc/os-release | grep PRETTY_NAME
确认当前权限身份
whoami
id
确认为普通用户身份，uid=1000，无 root 权限。这是攻击前的基准状态。
确认 AF_ALG 可用
python3 -c “import socket; s = socket.socket(38, 5, 0); print(‘AF_ALG available’); s.close()”
执行poc
从普通用户（uid=1000）到 root（uid=0），一条命令完成提权
修复方案
官方补丁
内核已经合入了修复补丁
改回 Out-of-place 模式——源缓冲区和目标缓冲区各用各的内存，从根本上消除只读页缓存被意外写入的可能。
临时缓解
生产系统如果暂时不能升内核，可以这么处理：
1.禁用AF_ALG模块
modprobe -r algif_aeadecho "blacklist algif_aead" >> /etc/modprobe.d/blacklist-crypto.conf注意：这会影响IPsec、WireGuard等依赖内核加密的服务，评估后再操作。
2.容器环境加Seccomp限制
在Seccomp配置中禁止AF_ALG（family 38）的socket调用，阻止容器内的利用。
3.AppArmor限制
在AppArmor profile中禁止AF_ALG的创建。
终极方案
升内核
# Ubuntu/Debiansudo apt update && sudo apt upgrade linux-image-generic# RHEL/CentOSsudo yum update kernel# 然后重启sudo reboot
总结
CVE-2026-31431核心问题在于内核为了优化性能引入in-place操作时，没有处理好只读页缓存的边界条件。但恰恰是这个”没处理好”，让任何本地低权限用户都有能力拿到root权限。
具有以下几个特点
利用简单：无需竞态条件，732 字节 Python 脚本即可提权
跨发行版通用：所有主流 Linux 发行版均受影响
隐蔽性强：仅修改内存页缓存，不触碰磁盘文件
建议所有 Linux 系统管理员立即检查内核版本并应用安全补丁。对于暂时无法更新的生产系统，应通过 Seccomp/AppArmor 等安全机制限制 AF_ALG 接口的访问。
参考文献
https://access.redhat.com/security/cve/cve-2026-31431
https://ubuntu.com/security/CVE-2026-31431
https://www.suse.com/security/cve/CVE-2026-31431.html
https://xint.io/blog/copy-fail-linux-distributions
https://avd.aliyun.com/detail?id=AVD-2026-31431
https://thehackernews.com/2026/04/new-linux-copy-fail-vulnerability.html
https://seclists.org/oss-sec/2026/q2/290
END
01
CVE-2026-24061：潜伏11年的致命漏洞深度解析
02
AIReact2Shell 图形化漏洞检测利用工具
03
你的电脑里，有个”内鬼”叫DLL—–DLL劫持学习
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：SEVENTEENSEC Faithtiann Faithtiann《732字节Python脚本通杀所有Linux》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论