跳至内容
文章
Linux 页缓存写入型提权漏洞梳理：Copy Fail、DirtyFrag、Fragnesia 与 DirtyClone

Linux 页缓存写入型提权漏洞梳理：Copy Fail、DirtyFrag、Fragnesia 与 DirtyClone

2026-06-27·Zakk
Zakk

2026 年 3 月至 6 月，研究人员陆续报告或公开了多组能够修改 Linux 文件页缓存的本地提权漏洞。Copy Fail、DirtyFrag、Fragnesia 和 DirtyClone 经常被放在一起讨论，因为它们都能把只读文件映射成内核中的写入目标，但它们不是同一个漏洞，也不共享完全相同的触发条件。

Copy Fail 不属于 DirtyFrag 的同一根因：它发生在 AF_ALG；DirtyFrag、Fragnesia 和 DirtyClone 则集中在网络 skb、XFRM/ESP 或 RxRPC 路径。只缓解其中一条路径，不能证明其他路径也安全。

共同的利用结果

这些漏洞利用的共同点是 Linux 页缓存和零复制路径之间的内存共享：

  1. 攻击者以只读方式打开 /usr/bin/su 等特权程序，使目标页面进入页缓存；
  2. splice()、vmsplice() 或相关零复制路径让内核缓冲区继续引用同一物理页；
  3. 加密或解密代码在原地写回数据，但没有先建立私有副本；
  4. 页缓存中的可执行代码被修改，磁盘文件通常保持不变；
  5. 再次执行目标程序时，内核使用已被修改的缓存页面，攻击者由此取得 root 权限。

这里的关键不是绕过文件权限直接写磁盘，而是让内核误把仍与只读文件共享的页面当成可写缓冲区。因为修改发生在内存中，磁盘完整性检查可能看不到变化。

这一共同模型分别见于 Copy Fail 原始公告、DirtyFrag 原始研究、Fragnesia 原始研究和 JFrog 的 DirtyClone 分析。

差异一览

名称CVE主要问题旧内核的临时阻断方式
Copy FailCVE-2026-31431AF_ALG algif_aead 原地操作禁止 algif_aead，或用 seccomp 阻止 AF_ALG socket
DirtyFrag（ESP）CVE-2026-43284UDP splice 分片未正确标记，ESP 对共享分片原地解密阻止取得 CAP_NET_ADMIN，或禁止 esp4、esp6
DirtyFrag（RxRPC）CVE-2026-43500RxRPC 未对外部共享分片建立私有副本禁止 rxrpc；关闭 user namespace 单独无效
FragnesiaCVE-2026-46300skb_try_coalesce() 合并分片时丢失共享标志阻止取得 CAP_NET_ADMIN，或禁止 esp4、esp6
DirtyCloneCVE-2026-43503多个分片转移函数未传递共享标志阻止取得 CAP_NET_ADMIN，或禁止 esp4、esp6

更新内核始终是首选。表中的模块和 namespace 设置只适合无法立即更新的旧系统，而且必须结合实际内核配置验证是否生效。

Copy Fail：AF_ALG 原地操作

Copy Fail（CVE-2026-31431）位于内核加密接口 AF_ALG。algif_aead 曾对来自不同映射的源和目标执行原地操作，使与文件页缓存共享的页面进入可写目标 scatterlist。公开利用通过 AF_ALG、splice() 和 authencesn 构造受控写入，不需要网络连接、用户命名空间或 CAP_NET_ADMIN。原始公告给出了利用条件、修复提交和披露时间线。

上游修复 a664bf3d603d 撤销了 2017 年引入的 algif_aead 原地优化，恢复源、目标分离。无法更新时可禁止模块：

printf '%s\n' 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif-aead.conf
modprobe -r algif_aead

对于容器、CI runner 等不受信任工作负载，还可以通过 seccomp 禁止创建 AF_ALG socket。该措施只覆盖 Copy Fail，不会阻止 DirtyFrag 的 ESP 或 RxRPC 路径。

DirtyFrag：两条漏洞链在一起

根据原始研究，DirtyFrag 不是单一 CVE，而是公开利用中串联的两条页缓存写入路径：

  • CVE-2026-43284（XFRM/ESP）：IPv4/IPv6 的 UDP splice 路径没有为外部共享分片设置 SKBFL_SHARED_FRAG，ESP 随后跳过写时复制并原地解密。
  • CVE-2026-43500（RxRPC）：RxRPC 过去只在 skb 已克隆时建立私有线性副本，没有覆盖仍持有外部共享分页分片的 skb。

ESP 路径写入能力强、模块普遍存在，但配置 XFRM 通常需要在网络命名空间中取得 CAP_NET_ADMIN。RxRPC 路径不要求创建 user namespace，却依赖系统提供并加载 rxrpc 模块。原始研究将两条路径组合，是为了覆盖不同发行版的默认配置，而不是因为两者必须同时触发。

两条主线修复分别是 f4c50a4034e6 和 aa54b1d27fe0。

Fragnesia：合并 skb 时丢失标志

Fragnesia（CVE-2026-46300）是独立的后续漏洞。skb_try_coalesce() 把来源 skb 的分页分片挂到目标 skb 时，没有同步 SKBFL_SHARED_FRAG。后续 ESP 代码因此认为目标 skb 没有共享分片，并在页缓存页面上原地解密。V12 的原始说明记录了利用模型、受影响条件和临时缓解。

公开利用使用 ESP-in-TCP：先把文件页面 splice 到 TCP 接收队列，再切换到 espintcp ULP 处理已有数据。攻击者在新建的 user/network namespace 中取得 CAP_NET_ADMIN，配置 XFRM 状态并控制 AES-GCM 参数，最终逐字节修改 /usr/bin/su 的页缓存副本。

DirtyClone：标志在更多转移路径中丢失

DirtyClone 是 JFrog 对 CVE-2026-43503 中 __pskb_copy_fclone() 利用变种的命名。按照 JFrog 的技术分析，攻击者使用 netfilter TEE 或等价的 nf_dup_ipv4() 路径复制数据包；复制后的 skb 继续引用文件页缓存，却没有保留共享分片标志。它随后进入 ESP 原地解密路径，形成受控写入。

CVE-2026-43503 的上游修复不只处理 __pskb_copy_fclone()，还覆盖 skb_shift()、skb_segment()、skb_gro_receive()、skb_gro_receive_list() 和 tcp_clone_payload() 等分片转移函数。主线提交为 48f6a5356a33，5 月 21 日合并；首个包含修复的主线标签是 5 月 24 日发布的 v7.1-rc5。

详细的 Gentoo 更新和临时缓解命令参见：Linux 内核 DirtyClone 本地提权漏洞：Gentoo 更新建议。

为什么修复会连续出现

最初的修复处理了会直接写入共享页面的加密路径，也开始使用 SKBFL_SHARED_FRAG 标记外部分片。后续研究发现，只要某个 skb 合并、复制或分片转移函数没有传递该标志，写入端仍可能把共享页面误判为私有页面。

因此这些补丁不是简单重复：DirtyFrag 修正初始标记和写入端检查，Fragnesia 修正合并路径，CVE-2026-43503 再补齐其他分片转移路径。JFrog 的结论是，只有应用整组已知修复，才能覆盖当前公开的利用模型。

披露与修复时间线

日期事件
2026-03-23Copy Fail 报告给 Linux 内核安全团队
2026-04-01Copy Fail 修复进入主线
2026-04-22CVE-2026-31431 发布
2026-04-29Copy Fail 公开披露；DirtyFrag/RxRPC 的漏洞详情和补丁提交内核安全团队及 netdev
2026-04-30DirtyFrag/ESP 的漏洞详情和初版补丁提交内核安全团队及 netdev
2026-05-01CVE-2026-43500 在 Linux CNA 记录中预留
2026-05-04DirtyFrag/ESP 的 shared-frag 方案补丁提交 netdev；它后来成为最终合并的修复
2026-05-07DirtyFrag/ESP 修复 f4c50a4034e6 合并到 netdev；DirtyFrag 研究完整公开
2026-05-08f4c50a4034e6 合并到主线；CVE-2026-43284 发布
2026-05-10DirtyFrag 的 RxRPC 修复进入主线
2026-05-11CVE-2026-43500 发布
2026-05-13Fragnesia 披露并向 netdev 提交修复；该提交在主线 linux.git 中的 committer date 为 5 月 14 日
2026-05-16覆盖多个分片转移函数的补丁写成并提交上游；这是 48f6a5356a33 的 author date
2026-05-19Gentoo 发布内核公告；JFrog 报告独立发现的 __pskb_copy_fclone() 变种
2026-05-21CVE-2026-43503 修复合并到主线
2026-05-23CVE-2026-46300 与 CVE-2026-43503 发布
2026-05-24Linux v7.1-rc5 发布，成为首个包含 CVE-2026-43503 修复的主线标签
2026-06-25JFrog 发布 DirtyClone 完整分析

时间线分别依据 Copy Fail 公告、DirtyFrag 详细时间线、Fragnesia 说明、JFrog 时间线、上游提交元数据和 Linux CNA 的 CVE 发布记录整理。

f4c50a4034e6 的补丁邮件头显示作者日期为 5 月 4 日、committer date 为 5 月 5 日，但这两个日期本身不是 netdev 或主线的合并日期。DirtyFrag 的详细时间线明确记录该补丁在 5 月 7 日进入 netdev、5 月 8 日进入主线。README 概述中“5 月 7 日公开时没有 patch 或 CVE”的注释与详细时间线所列的 4 月 30 日、5 月 4 日公开补丁不一致，因此本文以事件更完整、带有邮件列表及提交链接的详细时间线为准，不用该注释推导合并时间。

每个漏洞在哪个版本修复

下表按 Linux CNA 的 CVE JSON、上游提交元数据和原始研究整理。“上游修复记录”明确区分提交对象日期、子系统开发树和主线 linux.git；任何日期都不表示所有发行版从当天起自动安全，稳定分支和发行版仍需分别回移补丁。

漏洞上游修复记录Linux CNA 的主线修复版本Linux CVE 记录中的稳定分支修复版本
Copy Fail（CVE-2026-31431）2026-04-017.05.10.254、5.15.204、6.1.170、6.6.137、6.12.85、6.18.22、6.19.12
DirtyFrag/ESP（CVE-2026-43284）2026-05-07 进入 netdev；5 月 8 日进入主线7.15.10.255、5.15.205/206、6.1.171/172、6.6.138、6.12.87、6.18.28、7.0.5
DirtyFrag/RxRPC（CVE-2026-43500）2026-05-107.16.6.140、6.12.88、6.18.29、7.0.6；5.10、5.15、6.1 没有列出官方稳定版修复下限
Fragnesia（CVE-2026-46300）2026-05-13 披露并提交 netdev；该提交在主线 linux.git 中的 committer date 为 5 月 14 日7.15.10.257、5.15.208、6.1.174、6.6.141、6.12.91、6.18.33、7.0.10
DirtyClone（CVE-2026-43503）2026-05-16 提交；5 月 21 日合并；5 月 24 日发布首个修复标签7.1；首个修复标签为 v7.1-rc55.10.257、5.15.208、6.1.174、6.6.141、6.12.91、6.18.33、7.0.10

CVE-2026-43284 的 Linux CVE 记录目前在 5.15 和 6.1 分支各列出两个连续修复版本，表中如实保留。使用这两个分支时应选择较新的 5.15.206、6.1.172 或更高版本，并继续检查发行版是否回移了 CVE-2026-43500。

哪个版本以后才覆盖整条漏洞链

如果使用未经发行版额外打补丁的上游稳定内核，必须同时满足五个 CVE。下表是将五份 Linux CNA 记录逐分支比较、取其中最晚修复下限后得到的结果；它是对官方版本数据的汇总计算，不是某一份 CVE 记录单独给出的整组结论：

上游分支覆盖本文五个 CVE 的最低可确认版本结论
5.10无法只凭版本确认CVE-2026-43500 没有列出该分支的官方修复下限，必须核对发行版或自行回移的补丁
5.15无法只凭版本确认同上
6.1无法只凭版本确认同上
6.66.6.141该版本及以后覆盖五个 CVE
6.126.12.91该版本及以后覆盖五个 CVE
6.186.18.33该版本及以后覆盖五个 CVE
6.19无法只凭版本确认Linux CNA 只为 Copy Fail 列出 6.19.12，后续四个 CVE 没有列出 6.19 稳定版修复下限；应迁移到受维护分支
7.07.0.10该版本及以后覆盖五个 CVE
7.17.1正式版覆盖五个 CVE；CVE-2026-43503 从 v7.1-rc5 起已修复
不存在“某个日期以后编译的内核一定安全”这种判断方法。补丁在主线合并后，各稳定分支和发行版的回移时间不同；相反，发行版也可能在较旧的版本号上提前回移补丁。应同时检查内核分支、完整软件包版本和发行版安全状态。

Gentoo 用户如何判断是否安全

判断整个漏洞链是否修复，不能只检查某一个 CVE，也不能只看内核主版本。发行版可能提前回移补丁，也可能保留同一版本号而增加修订后缀。

Gentoo 在 5 月 19 日的公告中说明，sys-kernel/gentoo-kernel、sys-kernel/gentoo-kernel-bin 和 sys-kernel/gentoo-sources 是安全支持范围，当时已经包含最新的 Fragnesia v5 补丁。6 月 27 日可用的受支持版本也已经达到 CVE-2026-43503 的上游修复版本。

截至 2026-06-27，可作为 Gentoo 已知受保护基线的稳定软件包版本如下。“受保护”包括补丁修复，也包括 Gentoo 明确采用的功能停用缓解；不同架构的稳定关键字可能不同，应以本机 emerge -pv 的结果为准：

分支gentoo-kernel / gentoo-kernel-bingentoo-sources状态
5.10不再列为安全基线不再列为安全基线Gentoo 正在终止该分支的支持，计划于 2026-07-03 移除
5.15不再列为安全基线不再列为安全基线同上
6.16.1.174_p16.1.174-r1CVE-2026-43503 已修复；Gentoo patchset 将 AF_RXRPC 标为 BROKEN，阻断缺少上游回移的 RxRPC 路径
6.66.6.141_p16.6.141-r1当前稳定受保护基线
6.126.12.93 / 6.12.93-r16.12.93-r1当前稳定受保护基线
6.186.18.35 / 6.18.35-r16.18.35-r1当前稳定受保护基线

6.1 的处理可以在 gentoo-kernel / gentoo-kernel-bin 的 6.1.174_p1 patchset以及 gentoo-sources 的 genpatches-6.1-190.base 中核对：前者的 0013-net-rxrpc-mark-AF_RXRPC-as-BROKEN-and-reverse-depend.patch 和后者的 1525_net-rxrpc-mark-AF_RXRPC-as-BROKEN.patch 都将 AF_RXRPC 标记为 BROKEN。这是一项缓解，不应写成已经回移 CVE-2026-43500 的修复代码。

其他版本信息来自 Gentoo 软件包数据库：gentoo-kernel、gentoo-kernel-bin和 gentoo-sources。这里列的是 6 月 27 日仓库中的已知受保护稳定基线，不是永久固定的推荐版本。用户应同步仓库、更新到当前可用版本并重启，而不是继续停留在表中的最低版本或依赖临时 workaround。

测试分支方面，7.0.12 及以上的 gentoo-kernel / gentoo-kernel-bin / gentoo-sources 已超过上游 7.0.10 的完整修复下限；gentoo-sources 7.1.x 也包含整组修复。这些版本在 6 月 27 日仍使用 ~arch 关键字，不应与稳定分支混为一谈。

sys-kernel/vanilla-sources 不在 Gentoo 安全支持范围内。自行配置的内核、其他内核软件包或自行挑选补丁的用户，应分别核对以下五个 CVE：

  • CVE-2026-31431
  • CVE-2026-43284
  • CVE-2026-43500
  • CVE-2026-46300
  • CVE-2026-43503

尤其要注意：CVE-2026-43500 的官方稳定分支回移范围与其他漏洞不同，不能仅凭 CVE-2026-43503 的修复版本推断整个漏洞链已经补齐。

参考资料

最近更新
Gentoo Linux with ZFS（转载）Linux 内核 DirtyClone 本地提权漏洞：Gentoo 更新建议