DirtyClone: Linux 内核新漏洞,通过克隆的数据包获得根权限

该漏洞可导致本地用户通过克隆的网络数据包破坏文件支持的内存，获取 root 权限。该漏洞的补丁于 5 月 21 日合入主线；如果用户的内核尚未包含该补丁，应立即更新。

当内核在内部复制网络数据包时，两个辅助函数会丢弃一个用于标记与磁盘上某个文件共享的数据包内存的安全标记，而缺失的标志就是该漏洞的根源。攻击者将诸如 /usr/bin/su 等特权二进制文件加载到内存中，将这些内存页挂载到一个网络数据包中，并强制内核对其进行克隆。克隆后的数据包会经过攻击者控制的 IPsec 隧道，在解密步骤中，攻击者选定的字节会覆写该二进制文件中用于登录验证的检查代码。之后任何人再运行 su 命令时，它就会直接交出 root 权限。

磁盘上的文件从未改变。修改仅存在于内核的内存副本中，因此文件完整性检查工具无法发现，攻击不会留下审计痕迹，重启系统才能恢复原始二进制文件。而等有人想到要去检查时，攻击者早已拿到了 root 权限。利用该漏洞需要 CAP_NET_ADMIN 权限来配置回环 IPsec 隧道。非特权用户命名空间在 Debian 和 Fedora 尚默认启用，因此本地用户可以在新的命名空间内部获取该能力。

Ubuntu 24.04 及更高版本通过 AppArmor 限制了命名空间的创建，从而阻止了默认的利用路径。页缓存在主机级别是共享的，因此在命名空间内部所做的修改会影响机器上的所有进程。

受影响系统包括多租户服务器、CI 运行环境、容器主机，以及允许不可信用户创建命名空间的 Kubernetes 集群。JFrog 已在采用默认命名空间配置的 Debian、Ubuntu 和 Fedora 系统上确认了该利用的有效性。

共享片段标志位丢失的问题仍未根除

这是近期第四个具有相同失败模式的权限提升漏洞：文件支持的内存被当作数据包数据处理，然后一个原地网络操作直接写入本该执行复制操作的位置。其它三个如下：

虽然每个修复方案都关闭了一条代码路径，却又留下了其它路径。DirtyClone 已演示的利用核心围绕 __pskb_copy_fclone()，而 skb_shift() 同样受影响；更广泛的 CVE 修复覆盖了其他可能丢失相同标志的片段传输辅助函数。根本问题不在于某个坏的辅助函数。而是一个契约问题：每一条移动 skb 片段的代码路径，都必须不折不扣地每次都保留共享片段标志位。内核的零拷贝网络允许文件支持的内存作为数据包数据使用，而链中任何位置只要有一个标志被丢弃，就会将性能优化变成写入原语。每个变种都找到了一条未遵守该契约的路径。

原始 DirtyFrag 的研究者 Hyunwoo Kim 已于 5 月 16 日提交了一个更广泛的多站点补丁，覆盖了其余几个片段传输辅助函数。综合修复方案于 5 月 21 日合入（提交 48f6a5356a33），5 月 23 日分配了 CVE-2026-43503，并于 5 月 24 日在 Linux v7.1-rc5 中发布。

应对措施

安装所用发行版提供的内核更新。该修复方案已在上游 v7.1-rc5 中落地，并已向后移植到稳定版和 LTS 分支。Ubuntu、Debian 和 SUSE 已发布安全公告；Red Hat 在 Bugzilla 中有对应的跟踪条目。

如果无法立即修复，可采取两种临时措施可以减少攻击面。限制非特权用户命名空间：在 Debian 和 Ubuntu 上，设置 kernel.unprivileged_userns_clone=0（其它发行版使用不同的机制）。或者，将 esp4、esp6 和 rxrpc 内核模块加入黑名单，但这会破坏 IPsec 和 AFS 功能，且仅在这些功能是可加载模块而非编译进内核时才有效。这两种都只是临时控制措施，而非修复方案。

DirtyFrag 这一类漏洞很可能还会继续出现。任何在移动片段描述符时未能传递共享片段标志位的函数，都可能成为一个新的 CVE 漏洞，因此审计工作应覆盖在片段传输过程中触及 skb_shinfo()->flags 的每一条路径。