Dirty Frag CVE-2026-43284：Linux 本地提权漏洞风险与缓解指南

Dirty Frag 是 2026 年 5 月公开并已出现利用迹象的一组 Linux 内核本地提权漏洞。Microsoft 将其描述为攻击者在已经获得低权限执行能力后，用来把权限提升到 root 的后渗透风险；Ubuntu 也将 CVE-2026-43284 标为 High。

这类漏洞最危险的地方不在“远程直接打进来”，而在“进来以后迅速扩大控制权”。一旦攻击者通过弱 SSH 账号、WebShell、容器逃逸、低权限服务账号或钓鱼后的远程访问拿到本地执行机会，就可能利用 Dirty Frag 获取 root，进而关闭安全工具、读取敏感凭据、篡改日志、横向移动或建立持久化。

Dirty Frag 涉及哪些 CVE

目前公开信息里，Dirty Frag 主要关联两个编号：

CVE-2026-43284：涉及 Linux 内核 xfrm/ESP 路径，Microsoft 提到的 esp4、esp6 组件属于这一类风险。
CVE-2026-43500：Microsoft 称其与 rxrpc 相关，但截至 2026 年 5 月 8 日，该 CVE 在 NVD 尚未正式发布，补丁状态也仍在变化。

因此，实际排查时不要只盯一个 CVE。更稳妥的思路是同时关注 esp4、esp6、rxrpc 以及相关 xfrm/IPsec 功能是否启用、是否需要、是否已有发行版内核补丁。

技术原因简单理解

根据 Microsoft 和 Ubuntu 的说明，CVE-2026-43284 与 Linux 内核网络和内存碎片处理有关，尤其是 ESP/IPsec 路径中对共享页面片段的处理。

更具体地说，某些场景下，数据页可能通过 splice 等机制被挂到网络缓冲区里。如果内核后续路径把这些片段当成可以原地修改的私有数据处理，就可能在不该写的位置发生原地解密或修改。攻击者可以借此操纵 page cache 行为，最终达到本地提权。

这和此前披露的 CopyFail（CVE-2026-31431）有相似背景：都围绕 Linux page cache、内核数据路径和本地提权展开。Dirty Frag 的危险点在于，它引入了更多攻击路径，可能比传统依赖竞态窗口的 LPE 更稳定。

哪些环境需要优先关注

Dirty Frag 是本地提权漏洞，所以前提是攻击者已经能在目标机器上执行代码。需要优先关注的环境包括：

暴露 SSH 的 Linux 服务器。
运行 Web 应用、可能被写入 WebShell 的服务器。
多用户登录、跳板机、开发机、CI/CD runner。
容器宿主机、Kubernetes 节点、OpenShift 节点。
使用 IPsec、VPN、xfrm、RxRPC 相关功能的系统。
运行 Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE 等主流发行版的服务器。

如果你的服务器完全没有本地多用户、没有容器、没有暴露可被利用的应用入口，风险会低一些；但只要存在“攻击者可能拿到低权限 shell”的路径，就应该把它作为高优先级内核漏洞处理。

先做补丁优先

最稳妥的修复方式永远是安装发行版提供的内核安全更新，并重启进入新内核。

Ubuntu 的 CVE 页面显示，CVE-2026-43284 发布于 2026 年 5 月 8 日，优先级为 High。Microsoft 也指出 Linux Kernel Organization 已经发布 CVE-2026-43284 相关修复，并建议尽快应用补丁。

实际操作建议：

1
2


uname -a
cat /etc/os-release

然后按发行版更新内核：

1

sudo apt update && sudo apt full-upgrade

或：

1

sudo dnf update

更新后务必确认已重启到新内核：

1

uname -r

只安装内核包但不重启，旧内核仍在运行，漏洞依然可能存在。

临时缓解：禁用相关模块

如果补丁尚未可用，或生产环境不能立即重启，可以先评估是否能临时禁用相关模块。Ubuntu 给出的缓解思路是阻止 esp4、esp6、rxrpc 加载，并卸载已经加载的模块。

创建 modprobe 禁用规则：

1
2
3


echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

更新 initramfs，避免早期启动阶段加载：

1

sudo update-initramfs -u -k all

卸载已加载模块：

1

sudo rmmod esp4 esp6 rxrpc 2>/dev/null

确认模块是否仍在：

1

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

如果模块正在被业务使用，可能无法卸载，重启后禁用规则才会生效。

禁用前一定要评估业务影响

不要把上面的缓解命令当成无脑复制粘贴。esp4、esp6 和 xfrm/IPsec 相关功能可能被 VPN、隧道、加密网络、Kubernetes/容器网络或特定企业网络配置使用。rxrpc 也可能影响依赖该协议的场景。

在生产环境执行前，至少确认：

1
2
3


lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

如果你依赖 IPsec VPN 或相关内核网络功能，禁用模块可能直接导致连接中断。此时更推荐尽快安排内核补丁和维护窗口，而不是长期依赖禁用模块。

入侵后检查不能省

Microsoft 特别提醒，缓解措施不一定能撤销已经发生的成功利用。攻击者如果已经拿到 root，可能留下持久化、篡改文件、修改日志或访问 session 数据。

建议至少检查：

1
2
3
4
5


journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

还应重点关注：

异常 su、sudo、SUID/SGID 进程启动。
近期新增的 ELF 可执行文件。
Web 目录下的可疑 PHP、JSP、ASP 文件。
SSH authorized_keys 是否被改动。
systemd service、cron、rc.local 是否新增持久化。
容器宿主机是否有异常特权容器或挂载。

如果怀疑已经被利用，优先隔离主机、保留证据、轮换凭据，再做清理。不要只靠卸载模块或清缓存就认为安全。

关于 drop_caches

Microsoft 文中提到，在某些入侵后完整性验证场景，可以评估是否清理缓存：

1

echo 3 | sudo tee /proc/sys/vm/drop_caches

但这不是漏洞修复命令，也不是入侵清理命令。清 cache 可能带来额外磁盘 I/O 和生产性能影响，只适合在理解影响后作为辅助操作。真正的修复仍然是打补丁、重启、检查完整性和排查持久化。

总结

Dirty Frag 不是一个“远程一键打穿”的漏洞，但它会显著放大已经入侵后的风险。只要攻击者能获得本地低权限执行机会，就可能借助 CVE-2026-43284 以及相关 rxrpc 攻击面把权限提升到 root。

对管理员来说，重点不是研究 PoC，而是尽快完成三件事：确认内核是否受影响，安装发行版安全更新并重启；在补丁窗口前评估禁用相关模块；对已经暴露或疑似被入侵的系统做完整性和持久化检查。

参考链接：