
免责声明:本文漏洞技术细节均来源于公开可查证的安全研究资料,仅供安全研究和防御参考。请勿将文中技术细节用于非授权安全测试。受影响系统请尽快参照厂商安全公告进行修复。
Linux内核是全球使用最广泛的开源操作系统内核,由Linus Torvalds于 1991年发起开发,负责进程调度、内存管理、文件系统、设备驱动及网络协议栈等核心功能。从企业数据中心到云服务提供商,从 Android 手机到 Kubernetes 集群,数十亿台设备都依赖它运行。其网络子系统支持 TCP/IP、IPsec VPN、nftables 等高级功能,广泛部署于多租户云环境与容器编排平台中。
2026年5月,JFrog安全研究团队在审计Linux内核补丁时发现,尽管此前已修复DirtyFrag漏洞家族的多条路径,__pskb_copy_fclone()函数中仍残留同一类标志位丢失缺陷,由此催生了DirtyClone—— 一个允许非特权本地用户通过构造网络数据包、静默篡改内存中特权二进制文件以获取root权限的严重漏洞。
攻击不留磁盘痕迹、不触发文件完整性告警,一次重启即恢复原状,堪称2026年上半年最值得警惕的内核提权漏洞之一。
CVE-2026-43503是一个存在于Linux内核网络子系统的本地权限提升(LPE)漏洞,属于DirtyFrag漏洞家族的第四个变种。
漏洞根源在于:当内核通过 __pskb_copy_fclone()和 skb_shift()等辅助函数克隆或转移网络数据包分片(fragments)时,未能将 SKBFL_SHARED_FRAG标志位从源数据包传播到目标数据包。该标志位用于标记数据包是否引用了共享的文件页缓存(page cache)内存。
由于标志位丢失,后续IPsec ESP解密流程误判内存属性,跳过了必要的写时复制(Copy-on-Write)操作,直接在共享的只读文件内存页上执行原地解密写入。
攻击者可借此修改映射到内存中的特权二进制文件(如 /usr/bin/su),在磁盘文件完全不变的情况下,将认证逻辑篡改为任意指令,从而实现从普通用户到root的静默提权。
CVE-2026-43503
3.9 <= Linux Kernel < 5.10.257
5.11 <= Linux Kernel < 5.15.208
5.16 <= Linux Kernel < 6.1.174
6.2 <= Linux Kernel < 6.6.141
6.7 <= Linux Kernel < 6.12.91
6.13 <= Linux Kernel < 6.18.33
6.19 <= Linux Kernel < 7.0.10
7.1-rc1 <= Linux Kernel < 7.1-rc5
要理解DirtyClone,需要先理清Linux内核网络子系统中的三个关键概念:
1. 文件页缓存(Page Cache):当内核加载文件(如 ELF 可执行文件)时,文件内容被映射到内存中的页缓存,后续执行时直接从内存读取,避免重复磁盘 I/O。
2. Zero-Copy Networking:通过 vmsplice + splice 等系统调用,内核可以将页缓存内存直接作为网络数据包(skb)的负载数据,无需复制,以提升性能。
3. 原地加密/解密(In-Place Transform):IPsec ESP协议在处理网络数据包时,出于性能考虑,直接在原缓冲区上执行加密或解密操作——输入缓冲区即输出缓冲区。
当这三个概念交叉时,安全问题就出现了:如果数据包的内存恰好引用了文件页缓存,而原地解密又直接写入该内存,那么解密操作就变成了对文件页缓存的写入原语。内核引入了SKBFL_SHARED_FRAG标志位来防御这一风险:当该标志为真时,IPsec解密前会强制执行写时复制(Copy-on-Write),将数据复制到独立缓冲区后再操作。DirtyClone漏洞的本质,就是克隆路径丢失了这个标志位。
设计缺陷点评:
DirtyClone 暴露的不是某个函数的 bug,而是内核网络子系统中的一个系统性契约问题。SKBFL_SHARED_FRAG 标志的传播完全依赖每个frag-transfer辅助函数"自觉"维护——这本质上是一种约定式安全模型。从 Copy Fail(CVE-2026-31431)到 DirtyFrag(CVE-2026-43284)、Fragnesia(CVE-2026-46300)再到 DirtyClone,每个CVE都只关闭了一条路径,这种"打地鼠"式的修补模式说明:需要从架构层面重新审视文件页缓存与网络缓冲区之间的边界管理机制,而非逐个函数打补丁。
行业趋势思考:
2026 年上半年仅 DirtyFrag 家族就产生了四个 CVE,揭示了一个新的攻击范式——内核内存所有权元数据正在成为攻击面。未来的严重漏洞可能不是传统的堆溢出或 UAF,而是让内核"忘记"谁拥有某块内存的所有权。云原生环境的多租户特性放大了这一风险:容器和命名空间共享宿主机内核,一个容器内的页缓存篡改可能波及所有租户。安全团队的检测视角应从传统的内存破坏扩展到内存所有权管理领域。
可落地的排查建议:
第一,立即核查生产环境内核版本是否落入受影响范围,多租户环境(K8s 集群、CI Runner)优先升级;
第二,评估禁用非特权用户命名空间的可行性(sysctl -w kernel.unprivileged_userns_clone=0);
第三,对不使用 IPsec 的服务器,考虑将 esp4/esp6 模块加入黑名单;第四,建立 DirtyFrag 家族漏洞的专项跟踪机制——这个系列很可能还没结束。
https://github.com/0xBlackash/CVE-2026-43503
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48f6a5356a33dd78e7144ae1faef95ffc990aae0
— END —
漏洞分析不易,如果你觉得这篇文章对你的安全防护工作有帮助,请阅读至此的你随手点个红心,也欢迎转发给身边可能受影响的运维同事。每一个红心和转发,都是对安全内容创作的支持,也能让更多一线工程师及时获取漏洞预警信息。