导语：JFrog安全研究团队在审计Linux内核补丁时发现，尽管已有针对DirtyFrag漏洞家族的修复，但仍存在一个残余问题——攻击者可通XFRM/IPsec子系统中的不同数据包处理路径实现本地权限提升。该新变种被命名为"DirtyClone"，已分配CVE-2026-43503，CVSS评分8.8。
一、漏洞概述
DirtyClone是Linux内核内存损坏漏洞家族DirtyFrag的最新成员，专注于核心网络栈中socket buffer（skb）引用共享页缓存内存的方式，最终通in-place加密转换被武器化。
该漏洞的危险性在于：任何无权限的本地用户都可以通过操纵Linux页缓存获得root访问权限（LPE）。攻击无声无息，不留内核日志或审计痕迹，且能绕过常见的磁盘完整性监控工具。
影响范围
- 受影响发行版：Debian、Ubuntu、Fedora等启用了无特权用户命名空间的流行发行版
- 受影响内核：未完整应用DirtyFrag漏洞家族所有补丁的内核版本
- 高风险场景：多租户云环境、Kubernetes集群、启用了用户命名空间或特权容器的容器化工作负载
视频演示（原始来源）：https://jfrog.com/blog/dissecting-and-exploiting-a-new-dirtyfrag-variant-dirtyclone/
二、漏洞时间线
- 5月4日：DirtyFrag补丁（CVE-2026-43284和CVE-2026-43500）进入Linux内核主线，修复了spliced UDP数据包缺失SKBFL_SHARED_FRAG标志的bug
- 5月13日：Fragnesia（CVE-2026-46300）披露；补丁进入Linux内核netdev分支
- 5月16日：上游多站点补丁提交，覆盖剩余的frag-transfer辅助函数
- 5月19日：JFrog独立重新发现__pskb_copy_fclone变种，构建PoC并报告
- 5月21日：补丁合并到主线（commit 48f6a5356a33）
- 5月24日：Linux v7.1-rc5发布，首个修复版本
三、技术原理
3.1 核心问题
DirtyFrag系列漏洞的核心在于：现代Linux内核设计并没有严格区分三种可能重叠的内存角色：
当这三种上下文交叉时，内核可能会修改仍与文件语义关联的内存，导致文件备份数据被就地破坏。
攻击滥用了同一条物理内存页同时作为：
3.2 利用步骤
第一步：映射特权二进制文件
攻击者将特权二进制文件（如/usr/bin/su）映射到页缓存：
/usr/bin/su → 页缓存页（RAM）
该页成为后续操纵的目标。
第二步：构造IPsec数据包
攻击者精心构造一个有效载荷由同一页缓存页备份的IPsec数据包。使用vmsplice和splice系统调用，内核将页缓存备份的内存附加到skb，而不是复制数据：
int fd = open("/usr/bin/su", O_RDONLY);char *p = mmap(NULL, mmap_size, PROT_READ, MAP_SHARED, fd, 0);structioveciov = { .iov_base = p + patch_offset, .iov_len = 16 };vmsplice(pipefd[1], &iov, 1, 0);splice(pipefd[0], NULL, sockfd, NULL, 16, 0);
此时，数据包缓冲区实际上是由文件内存备份的。
第三步：本地环回IPsec隧道
攻击者使用基于环回的IPsec隧道，确保数据包保留在本地。这确保了：
当数据包到达ESP解密阶段（esp_input()）时，IPsec原地解密数据包以提高性能。这意味着输入缓冲区=输出缓冲区，解密后的字节覆盖同一内存。
通常这是安全的，但这里的缓冲区是由页缓存页备份的。如果skb数据位于源自文件映射的页备份缓冲区中，原地解密可能会修改该共享页内容。
第四步：控制解密输出
攻击者控制密码学输入（密钥、IV和数据包布局）。在AES-CBC中，IV影响第一个解密块。通过组合已知原始字节、选定密文结构和受控IV，攻击者可以在特定偏移处强制可预测的输出字节，从而在共享页备份缓冲区中影响解密结果。
第五步：修补su二进制
攻击者使用此原语修补/usr/bin/su中的小段指令序列。只需要几个字节（如控制认证的分支逻辑）。磁盘上的文件保持不变，但页缓存副本被修改：
原始su页 → IPsec写入原语 → 内存中已修改的su页
当再次执行/usr/bin/su时：
结果：权限提升。
四、DirtyFrag系列修复机制
原始DirtyFrag修复为spliced UDP数据包设置了SKBFL_SHARED_FRAG标志。这是标记引用共享（可能是文件备份）页内存的skb数据包的元数据标志，确保执行原地解密等操作的子系统触发安全的写时复制（Copy-on-Write）。
如果设置了这个标志，IPsec在解密前强制复制：
检测到共享页 → SKBFL_SHARED_FRAG = 1 → 复制skb → 安全解密
这可以防止直接修改文件备份页。
Fragnesia和CVE-2026-43503的修复确保SKBFL_SHARED_FRAG标志在函数间正确传播，不会意外"丢失"。
五、DirtyClone利用场景
5.1 环境配置
攻击者首先需要CAP_NET_ADMIN权限（通无特权用户命名空间通常可获得），以控制网络接口、路由和XFRM/IPsec策略。
攻击者创建一个新的网络命名空间：
unshare -Urn
然后配置基于环回的IPsec隧道：
ip linkset lo upip addr add 10.99.0.2/24 dev lo
创建IPsec（XFRM）状态：
ip xfrm state add \src 127.0.0.1 dst 127.0.0.1 \proto esp spi 0x12345678 reqid 1 mode transport \enc 'cbc(aes)' ... \auth 'hmac(sha1)' ...
添加匹配策略：
ip xfrm policy add \src 127.0.0.1 dst 127.0.0.1 dir out \tmpl src 127.0.0.1 dst 127.0.0.1 proto esp reqid 1 mode transport
最后添加netfilter规则：
iptables -t mangle -A OUTPUT -p udp --dport 4500 \-j TEE --gateway 10.99.0.2
5.2 TEE目标的关键作用
TEE目标在内核内部复制传出数据包，触发nf_dup_ipv4，最终导致通__pskb_copy_fclone()进行skb克隆。
当发送UDP数据包时：
- 内核调用__pskb_copy_fclone()创建克隆skb
此时存在两个skb对象：
关键：在克隆过程中，克隆的skb没有正确保留SKBFL_SHARED_FRAG标志。
这是DirtyClone绕过的根本原因：
六、原语转化与权限提升
两个skb实例都通过基于环回的IPsec配置路由。克隆的skb最终到达esp_input()。
此时，skb有效载荷不是普通网络内存，而是引用源自文件映射（如/usr/bin/su）的页缓存备份内存。内存布局如下：
文件备份页（页缓存） ├─ /usr/bin/su内容 └─ skb有效载荷引用
重要的是，skb不复制数据，而是引用同一物理页。这种共享引用使得跨所有DirtyFrag变种重用的页缓存写入原语成为可能。
当克隆的skb到达esp_input()时，IPsec对数据包有效载荷执行原地解密。解密后的字节直接写入文件备份页：
控制写入内容
攻击者可以控制：
在AES-CBC中，每个解密块依赖于IV。攻击者可以计算出一个IV，使输出变得可预测。结合已知原始字节、期望目标字节和受控IV，攻击者将解密转化为页缓存内存上的受控写入原语。
发送的数据包结构如下：
最终权限提升
使用此原语，攻击者修补/usr/bin/su内选的指令字节。典型修补目标包括认证检查和条件分支指令。只需要小的局部修改。磁盘文件保持不变，页缓存包含修改后的可执行代码。
当执行su时，Linux从页缓存加载二进制文件。如果修改后的页仍被缓存：
执行流程：
已修改页缓存 → 执行su → 修改后的逻辑运行 → 权限提升
七、修复建议
- 立即更新：将Linux内核更新到v7.1-rc5或应用CVE-2026-43503的 backported 补丁
- 临时缓解措施：如无法立即打补丁，可通过以下方式阻止CAP_NET_ADMIN获取：
- 设置kernel.unprivileged_userns_clone=0
- 黑名单esp4、esp6和rxrpc内核模块（阻止原地解密原语）
版权声明：本文由华安普特原创发布，保留所有权利。配图由华安普特授权使用。
👇 点击阅读原文，访问我的网站
10个月宝宝每天需要喝多少奶粉？
