Linux补丁刚合并,root漏洞就被猜出来了

_{图片来源：Unsplash}

Linux 内核刚合并一个安全补丁，漏洞利用代码就被公开了。

2026 年 5 月 7 日，一个叫 Dirty Frag 的本地提权漏洞被公开。它不是那种远程一扫就能打进来的漏洞。攻击者得先在机器上有一个普通账号，或者先通过别的入口混进去。

问题在于，只要攻击者已经进了系统，这个漏洞就可能把普通权限变成 root 权限。

研究者 Hyunwoo Kim 给出的说法很直接：这个漏洞可以在主流 Linux 发行版上拿到 root 权限。公开的验证代码已经能跑。临时处理办法也很直接：禁用 esp4、esp6、rxrpc 这几个内核模块，清掉页缓存，然后等发行版把修复送到用户机器上。

这不是管理员最想听到的那种公告。

它不是凭空冒出来的

Dirty Frag 最容易被误读成「又一个 Dirty Pipe」。

这个联想没错，但不够准。

2022 年的 Dirty Pipe、2026 年 4 月底公开的 Copy Fail，还有这次 Dirty Frag，背后都绕不开同一个危险动作：一个普通用户本来只该读某个文件，结果通过内核里的某条路径，把只读文件在内存页缓存里的内容改了。

磁盘上的文件可能没变。

但接下来系统再读那个文件，读到的已经是被动过手脚的版本。

危险就在这里。Linux 上有些文件本来就和权限有关，比如 /usr/bin/su，比如 /etc/passwd。研究者的演示里，一条路径把 su 在页缓存里的开头改成一段很小的 root shell；另一条路径则盯上 /etc/passwd 的第一行，让 root 的密码字段变空。

也就是说，攻击者不是直接修改磁盘文件，而是改了系统接下来会读到的内存副本。很多权限检查还没来得及意识到这里已经不一样了。

_{图片来源：V4bel/dirtyfrag GitHub 仓库}

问题出在补丁公开之后

这次需要单独拿出来说的，不只是漏洞本身，而是它怎么被公开。

时间线很短。

2026 年 4 月 29 日，研究者先把 rxrpc 这条路径报给了 Linux 内核安全团队，并把补丁发到了公开邮件列表。

2026 年 4 月 30 日，esp 这条路径也被报上去，补丁同样出现在公开列表里。

2026 年 5 月 4 日，另一位开发者 Kuan-Ting Chen 提交了更完整的修复思路。2026 年 5 月 7 日，这个修复合进了 netdev 代码树：给通过 splice 进来的共享页打标记，遇到这种外部挂进来的数据，ESP 解密不能再偷懒原地改，必须走拷贝路径。

补丁本身看起来很正常。

问题是，安全补丁本身也会暴露信息。开发者改了哪几行、加了什么判断，懂内核的人就能反推：原来的代码为什么不安全。

这次就是这样。补丁刚合并，就有人根据补丁猜出了漏洞形状，写出了利用代码。原本准备协调披露的节奏被打断，研究者只好把完整文档和验证代码一起放出来。

这也是开源安全很难处理的一点：代码必须公开，补丁也必须公开；但在发行版把补丁送到用户机器之前，公开补丁本身就可能变成攻击提示。

为什么这次大家紧张

Dirty Frag 由两条路拼起来。

一条是 xfrm-ESP。它影响面更广，写入能力也更直接，但通常需要能创建用户命名空间。很多系统允许普通用户创建，部分 Ubuntu 环境会被策略拦住。

另一条是 RxRPC。它不需要创建用户命名空间，但模块不是每个发行版默认都有。偏偏在 Ubuntu 上，这条路又更容易碰到。

两条路各有盲区，拼在一起，盲区就小了很多。

研究者列出的测试环境包括 Ubuntu 24.04.4、RHEL 10.1、openSUSE Tumbleweed、CentOS Stream 10、AlmaLinux 10、Fedora 44。影响时间也不好看：esp 相关问题可追到 2017 年 1 月，rxrpc 相关问题可追到 2023 年 6 月。

这里不要把「本地提权」看轻了。

云服务器、CI 构建机、多人共用的实验环境、跑用户代码的沙箱，都需要认真看待这类漏洞。第一步进来可能只是一个普通权限；第二步提到 root，整台机器就不再可信了。

_{图片来源：Unsplash}

现在能做什么

最稳的办法当然是等发行版补丁，并尽快更新内核。

在补丁没到之前，研究者给出的临时办法是禁用相关模块：

TERMINAL
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

这不是无成本操作。真在用 IPsec、RxRPC 或相关能力的机器，不能照抄就跑。生产环境要先看业务依赖。

但如果一台服务器根本用不到这些模块，问题就很直接：这些功能为什么要默认开着？

很多安全事故不是因为某个模块写得特别差，而是因为系统默认带了太多复杂功能。平时它们看起来没什么存在感，一旦出漏洞，管理员才发现自己其实一直在承担这部分风险。

Dirty Frag 留下的不是一个新名字。

它留下的是一个更现实的问题：当一个补丁本身就足够让人猜出漏洞时，开源世界到底该怎么同时做到透明和保护用户？

这件事没有简单答案。