安全 on KnightLi的博客

Dirty Frag、Copy Fail 与 Fragnesia：近期三个 Linux 本地提权漏洞对比

Fri, 15 May 2026 13:24:04 +0800

最近 Linux 内核连续出现几个高关注度的本地提权漏洞：Dirty Frag、Copy Fail 和 Fragnesia。它们看起来像一组“同类事件”，因为最终效果都很接近：低权限本地用户可能把权限提升到 root。

但从运维处置角度看，不能把它们混成一个漏洞。三者的入口模块、触发路径、缓解方式和补丁节奏都不同。更准确的理解是：它们暴露了 Linux 内核在“页缓存、splice、socket buffer、加密路径”这些复杂交界处的共同风险。

本文只做风险和处置分析，不展开可复现利用步骤。

三个漏洞分别是什么

Dirty Frag：CVE-2026-43284

Dirty Frag 主要指向 Linux 内核网络路径里的页缓存写入问题。公开资料中，它通常和两个问题一起讨论：xfrm-ESP 侧的 CVE-2026-43284，以及 rxrpc 侧的 CVE-2026-43500。

其中 CVE-2026-43284 与 ESP 处理共享 skb fragment 时的原地解密有关。问题的关键不是攻击者直接修改磁盘文件，而是让内核在不该写的共享页上发生写入，进而影响页缓存里的文件内容。

运维上最需要记住的是：Dirty Frag 触达的是 esp4、esp6、rxrpc 这一组内核模块和网络子系统路径。它和 IPsec、ESP、RxRPC 相关，临时缓解也会围绕这些模块展开。

Copy Fail：CVE-2026-31431

Copy Fail 是 Theori / Xint Code 披露的 Linux 内核本地提权漏洞。它的入口不在 IPsec 网络路径，而在内核用户态加密 API 的 algif_aead / AF_ALG 相关路径。

公开说明中提到，它源于 2017 年引入的一处原地优化：某些情况下，内核没有按预期复制数据，而是把页缓存页放进可写目标路径里。攻击者可以借助 AF_ALG 与 splice() 组合，对页缓存支持的页面做小范围可控写入。

它的风险点在于可利用性很强，而且影响面跨多个主流发行版。和 Dirty Frag 不同，Copy Fail 的临时缓解重点是限制或禁用 algif_aead，以及在容器和 CI 环境中限制 AF_ALG socket。

Fragnesia：CVE-2026-46300

Fragnesia 是 V12 Security 披露的另一个 Linux 内核本地提权漏洞，和 Dirty Frag 属于相近攻击面。它不是 Dirty Frag 的同一个 bug，但仍然围绕 IPsec ESP / rxrpc 相关模块，以及页缓存写入效果展开。

AlmaLinux 的说明把它定位为同一代码区域里的第三个本地 root 问题。其关键点在于 skb_try_coalesce() 在合并 socket buffer 片段时没有正确保留共享 fragment 标记，导致后续 XFRM ESP-in-TCP 接收路径可能在外部页缓存页上做原地解密。

也就是说，Fragnesia 和 Dirty Frag 更接近：两者都绕着 esp4、esp6、rxrpc、skb fragment、ESP 解密路径转。它们的临时缓解也高度重叠。

相同点：为什么都危险

这三个漏洞的共同点不是“代码位置完全一样”，而是攻击结果和风险模型非常像。

第一，它们都是本地提权。攻击者通常需要先在机器上获得普通用户代码执行能力，然后再把权限提升到 root。对单用户桌面来说，它不是远程一键入侵；但对多用户服务器、CI runner、容器宿主机、共享开发机和暴露 SSH 的 VPS 来说，低权限入口并不罕见。

第二，它们都和页缓存写入有关。攻击者不一定永久改写磁盘文件，而是影响内存中的页缓存副本。这会让传统文件完整性检查变得不够可靠：磁盘 hash 可能正常，但执行路径读到的页缓存内容已经被污染。

第三，它们都偏向确定性逻辑漏洞，而不是传统意义上很吃时序的竞争条件。公开资料多次强调这类漏洞不依赖赢得 race condition。对防守方来说，这意味着“利用成功率”不能按老经验低估。

第四，它们都放大了容器和自动化执行环境的风险。容器内的低权限代码、CI 任务、构建脚本、第三方插件，一旦能触达宿主内核相关接口，就可能把漏洞从“本地问题”变成“平台问题”。

不同点：不要用一个补丁思路套全部

三者最大的区别在入口模块。

Copy Fail 的关键入口是 algif_aead / AF_ALG，属于内核用户态加密 API。它的临时防护重点是禁用或限制 algif_aead，以及用 seccomp 阻断容器里创建 AF_ALG socket。

Dirty Frag 的关键入口在 xfrm-ESP 和 rxrpc。它更接近网络协议和 socket buffer 处理路径，临时防护通常会考虑禁用 esp4、esp6、rxrpc。但这可能影响 IPsec、VPN、隧道或相关网络能力。

Fragnesia 的入口也在 Dirty Frag 相近区域，但具体问题落在 skb_try_coalesce() 没有保留共享 fragment 标记。它更像是 Dirty Frag 风险面里的另一个分支，而不是 Copy Fail 的加密 API 问题。

所以，不能因为已经处理了 Copy Fail，就认为 Dirty Frag 和 Fragnesia 也被覆盖；也不能因为禁用了 esp4 / esp6，就认为 Copy Fail 自动消失。它们需要分别确认补丁状态和缓解策略。

影响范围该怎么判断

判断这类漏洞是否受影响，不要只看发行版名字，也不要只看内核大版本号。发行版会回合补丁，云厂商会维护自己的内核分支，企业发行版还可能有额外 backport。

更稳妥的顺序是：

先看发行版安全公告和内核包 changelog。
再核对 CVE 是否已被当前内核包修复。
对云主机、容器宿主机和 CI 节点，额外关注云厂商或平台方公告。
对临时缓解，确认业务是否依赖对应模块。
完成内核升级后安排重启，确保实际运行内核已经切换。

这一步最容易踩坑的是“包已经更新，但机器还没重启”。内核漏洞不是普通用户态服务升级，安装新包之后，旧内核仍可能继续运行。

运维优先级

这些漏洞最该优先处理的机器，不是“所有 Linux 平均排队”，而是低权限代码最容易出现的地方。

优先级最高的环境包括：

多用户登录服务器
CI / CD runner
构建机和制品打包机
容器宿主机和 Kubernetes 节点
共享开发机
暴露 SSH 的云主机和 VPS
运行第三方脚本、插件、任务队列的平台
有 Web 漏洞、弱口令或历史入侵痕迹的机器

相对封闭、单用户、没有外部代码执行入口的机器，风险仍然存在，但处置顺序可以排在后面。

临时缓解应该怎么理解

临时缓解不是补丁替代品。它的价值是帮你在无法立刻重启或等待发行版补丁时降低暴露面。

对 Copy Fail，重点关注 algif_aead 和 AF_ALG。如果业务没有使用内核 AF_ALG 加密接口，可以评估禁用相关模块；容器环境则应优先检查 seccomp 策略，避免不受信任工作负载随意创建对应 socket。

对 Dirty Frag 和 Fragnesia，重点关注 esp4、esp6、rxrpc。如果系统不依赖 IPsec ESP、相关 VPN、隧道或 RxRPC，可以评估临时禁用。但生产环境不要盲目执行，因为这些模块可能影响真实网络业务。

最终仍然要回到内核更新。临时缓解只能减少攻击面，不能证明系统已经彻底安全。

这三个漏洞说明了什么

这组漏洞真正值得警惕的地方，不只是 CVE 数量，而是它们都集中在内核高复杂度路径：零拷贝、splice、socket buffer、页缓存、加密接口、协议栈优化。

这些路径的共同特点是性能收益很大，但所有权边界也更难维护。一个 fragment 是否共享、一个页面是否还能原地写、一个优化是否真的只是减少复制，都会变成安全边界的一部分。

对安全团队和运维团队来说，结论很实际：

本地提权漏洞要按“已有低权限入口会被放大”处理。
容器不是内核漏洞的天然隔离边界。
文件完整性检查不能只看磁盘内容。
CI、构建机、插件平台要当成高优先级资产。
内核补丁需要验证“已安装”和“已运行”两个状态。

小结

Dirty Frag、Copy Fail 和 Fragnesia 都是近期 Linux 本地提权风险里的高优先级事件，但它们不是同一个漏洞的三个名字。

Copy Fail 走的是 algif_aead / AF_ALG 加密接口路径；Dirty Frag 走的是 xfrm-ESP 与 rxrpc 相关路径；Fragnesia 则在 Dirty Frag 相近攻击面上，通过 skb fragment 标记处理问题再次触发页缓存写入风险。

处置上，最稳妥的做法是：按发行版公告升级内核并重启；对无法立即升级的系统，分别按漏洞入口评估临时禁用模块或收紧 seccomp；对多租户、CI、容器宿主机和共享开发环境优先处理。

参考资料：

Theori Copy Fail 说明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail 安全公告：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 说明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 说明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 说明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux 内核本地提权漏洞影响与缓解

Fri, 15 May 2026 13:18:01 +0800

Linux 内核最近又曝出一个和 Dirty Frag 同一类攻击面相关的本地提权漏洞：Fragnesia (CVE-2026-46300)。

根据 V12 Security 的披露，Fragnesia 是一个 Linux 本地提权漏洞。攻击者不需要宿主机已有高权限，只要能在本地执行代码，就可能借助内核 XFRM ESP-in-TCP 子系统中的逻辑缺陷，把只读文件的页缓存内容按字节改写，最终触发 root shell。

原始资料：

V12 Security PoC 说明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

这篇不展开可复现利用步骤，只整理运维侧需要知道的风险点和处置思路。

它和 Dirty Frag 是什么关系

V12 Security 在说明中把 Fragnesia 归到 Dirty Frag 漏洞类别里。它不是 Dirty Frag 本身的同一个 bug，而是同一攻击面上的另一个问题：Linux 内核的 XFRM ESP-in-TCP。

XFRM 是 Linux 内核里处理 IPsec 的框架。ESP-in-TCP 则和通过 TCP 承载 ESP 加密流量有关。Fragnesia 的问题出在共享页碎片和 socket buffer 合并过程中的逻辑处理：某些情况下，内核会“忘记”某个 fragment 仍然是共享状态，从而留下可控写入空间。

这类问题让人联想到 Dirty Pipe / Dirty Frag 这一类页缓存写入漏洞。共同点不是具体代码完全相同，而是都把攻击效果落到了页缓存里的只读文件副本上。

风险为什么高

Fragnesia 的危险之处有三个。

第一，它是本地提权。只要攻击者已经能在系统上运行普通用户代码，就可能把权限提升到 root。对多用户服务器、容器宿主机、CI runner、共享开发机、VPS 和暴露 Shell 的环境来说，这类漏洞比普通桌面更敏感。

第二，它不依赖传统竞争条件。V12 的说明中提到，该漏洞通过构造 ESP-in-TCP 处理流程，让内核把加密流处理到已经 splice 进 socket buffer 的文件页上，进而按字节影响页缓存内容。这意味着风险不只是“理论上可能”，而是研究团队已经验证了稳定利用路径。

第三，它改的是页缓存，不是磁盘文件。公开说明里的示例目标是 /usr/bin/su。利用成功后，磁盘上的文件并不会被永久改写，改动存在于内存页缓存中。很多只检查磁盘文件 hash 或完整性的巡检流程，可能看不出异常。

这也是它对管理员麻烦的地方：系统看起来文件没变，但一旦执行被污染页缓存里的目标二进制，就可能触发提权效果。

已知影响范围

V12 Security 的说明称，受 Dirty Frag 影响且没有应用 2026 年 5 月 13 日相关补丁的内核，也会受 Fragnesia 影响。公开验证环境包括 Ubuntu 22.04、Ubuntu 24.04，以及 6.8.0-111-generic 这类内核版本。

这里要注意两个点。

第一，不要只看发行版大版本。Ubuntu 22.04 / 24.04 是否受影响，最终取决于内核补丁状态，而不是发行版名字。

第二，不要只看有没有默认 AppArmor 限制。Ubuntu 对非特权用户命名空间的 AppArmor 限制可以提高门槛，但披露方明确把它视为额外绕过问题，不是漏洞本体的根治方式。

真正可靠的判断方式，仍然是查看发行版安全公告和内核包更新。

临时缓解思路

如果系统暂时不能立刻升级内核，可以先评估是否依赖相关协议模块。

V12 给出的缓解方向与 Dirty Frag 相同：如果系统不依赖 IPsec ESP 或 RxRPC，可以禁用相关模块，例如 esp4、esp6、rxrpc。这类操作会影响相关网络能力，生产环境不要盲目执行，应该先确认业务是否使用 IPsec、VPN、隧道或相关内核功能。

更稳妥的处置顺序是：

确认发行版是否已经发布内核安全更新。
优先安装内核补丁并安排重启。
如果无法立即升级，再评估临时禁用相关模块。
对多用户系统和 CI / 构建环境优先处理。
检查是否开放非必要本地账号、Shell、容器逃逸面和低权限执行入口。

这里不要把禁用模块当作最终修复。它更像临时降低暴露面。

如果怀疑已经被利用

Fragnesia 的一个特点是页缓存污染。V12 在说明中强调，利用后目标文件在页缓存中的副本可能含有注入内容，后续执行仍可能触发异常行为，直到页面被驱逐或系统重启。

如果怀疑系统已经被利用，至少要做几件事：

尽快保留现场日志和审计记录。
检查近期异常本地登录、低权限用户活动、可疑进程和 root shell 痕迹。
清理相关页缓存或直接重启。
升级到已修复内核。
对关键二进制做完整性检查，但不要只依赖磁盘 hash。
轮换可能已经暴露的凭据和密钥。

如果是生产服务器，更建议把它当作一次潜在本地提权事件处理，而不是只当作普通补丁升级。

运维侧该优先看哪些机器

这类漏洞优先级最高的不是所有 Linux 机器平均处理，而是先看攻击者最容易拿到低权限代码执行的地方。

优先级较高的环境包括：

多用户登录服务器
CI / CD runner
构建机
共享开发机
容器宿主机
VPS 和云主机
暴露 SSH 的边缘节点
运行第三方脚本或插件的平台

相对封闭、单用户、没有外部代码执行入口的机器，风险仍然存在，但紧急程度可以低一些。

小结

Fragnesia 值得关注，不是因为它名字新，而是因为它再次把 Linux 本地提权问题拉回到页缓存和内核网络子系统这一类复杂交界处。

对管理员来说，最重要的不是研究利用细节，而是确认内核补丁状态、评估是否依赖 ESP / RxRPC、对高暴露机器优先升级，并理解“磁盘文件没变”不等于“系统没有被影响”。

如果系统受影响，最终答案仍然是尽快安装发行版提供的内核更新。临时禁用模块只能算过渡措施，不能替代补丁。