最近几周，Linux 世界被一个新的漏洞所震惊，对许多管理员来说，这无疑是压垮骆驼的最后一根稻草，因为此前已经出现了一系列严重的内核缺陷。我们说的就是…… Fragnesia，一种本地权限提升漏洞利用程序 这又为已知的故障案例系列增添了一笔。 复制失败 y 脏碎片这使得任何非特权用户都可以通过一条命令在易受攻击的系统上获得 root 权限。
继 Copy Fail 和 Dirty Frag 之后，Fragnesia 的出现正值系统补丁疲劳期：紧急更新、连续重启和紧急修复措施接踵而至。然而，忽视它并非良策。 该漏洞影响多个 Linux 发行版和内核版本目前已经存在一个功能齐全的公开概念验证版本。在本文中，我们将详细介绍 Fragnesia 是什么，攻击是如何进行的，哪些发行版会受到影响，有哪些补丁和缓解措施，以及如何检查您的系统是否受到保护。
什么是 Fragnesia？它与 Dirty Frag 和 Copy Fail 有什么关系？
Fragnesia 是一种 新的本地权限提升 (LPE) 漏洞利用 Linux 内核中存在一个漏洞，与 Copy Fail (CVE-2026-31431) 和 Dirty Frag（也称为 Copy Fail 2，CVE-2026-43284）属于同一类漏洞。该漏洞与它们的基本思路相同：利用内核网络协议栈和内存管理中的逻辑缺陷，获取内存写入原语，从而修改理论上只读的文件，并最终以 root 用户身份执行代码。
该裁决被称为 Fragnesia，追踪编号为 CVE-2026-46300该漏洞的 CVSS 评分为 7,8。V12 安全团队的 William Bowling 发现了该漏洞。不久之后，Sam James 在 OSS Security 邮件列表中公布了该问题，并澄清这并非对 Dirty Frag 漏洞的简单重新分析，而是内核同一功能层上的另一个漏洞。
实际上，弗拉格尼西亚是 短短两周内发生的第三次此类重大故障Copy Fail、Dirty Frag 和 Fragnesia 这三个漏洞都利用内核数据处理问题来破坏关键文件的页面缓存，例如 /usr/bin/su但 Fragnesia 通过另一种途径实现了这一点：XFRM 的 ESP-in-TCP 子系统。
技术细节：XFRM ESP-in-TCP 子系统和逻辑故障
Fragnesia 的核心位于 Linux XFRM ESP-in-TCP 子系统的逻辑故障具体来说，在名为 espintcp 的 ULP（上层协议）路由中。XFRM 是内核框架，负责处理 IPsec 流量等，而 ESP（封装安全有效载荷）协议通过加密（例如 AES-GCM）提供机密性和真实性，就像 CAN BCM 网络协议中的漏洞一样。
该攻击基于一个非常特殊的内核情况： 当 TCP 套接字切换到 ESP-in-TCP 模式时 在文件页通过诸如此类的调用被添加到其接收队列之后。 splice(2) o sendfile(2)内核不会将这些数据视为文件中的简单页面，而是将其解释为 ESP 密文并对其进行“解密”，从而就地修改缓存页面。
由于此错误，内核会将 AES-GCM 密钥流注入到 缓存页面对应于只读文件这会导致对页面缓存进行任意字节写入。通过控制初始化向量（随机数）和其他参数，非特权用户可以精确地控制这些写入操作。最终形成了一种确定性的写入原语，允许对任何可读文件进行可控字节数的修改，即使文件系统将其标记为不可变或只读。
公开的概念验证侧重于 修改二进制文件 /usr/bin/su 在页面缓存中它会将一个 192 字节（位置无关）的 ELF 存根注入到该二进制文件的内存副本中。从那时起，下次执行该二进制文件时，它就会被注入。 su该存根将以 root 权限运行，无需条件运行或其他额外技巧即可立即爬取权限。
临时缓解措施：如果无法重启，如何保护自己
虽然建议这样做 安装打过补丁的内核并尽快重启。对于那些无法立即重启系统的用户，已经提出了一些有效的临时缓解措施。好消息是，由于 Fragnesia 与 Dirty Frag 使用相同的底层模块（esp4、esp6 以及可选的 rxrpc），因此针对 Dirty Frag 提出的缓解措施也适用于 Fragnesia。
该技术包括 阻止加载易受攻击的模块 通过配置 modprobe 如果它们已经加载，则从内存中卸载它们。这是通过编写一条规则来实现的。 /etc/modprobe.d/ 它将加载这些模块的操作替换为无害的命令（例如： /bin/false然后就有人调用 rmmod 对于它们，如果错误不存在，则默默忽略它们。
在 CloudLinux 等发行版中，Dirty Frag 的建议命令（同样适用于 Fragnesia）会生成一个文件。 dirtyfrag.conf 文件包含以下规则 esp4, esp6 y rxrpc它还会尝试卸载活动模块。如果您已经针对 Dirty Frag 应用了此缓解措施， 对于 Fragenesis，你不需要做任何其他事情。 直到安装修正后的内核，因为攻击面也会被消除。
兼容性是一个需要考虑的重要因素： esp4 和 esp6 是 IPsec 的内核转换。禁用这些模块会破坏依赖于内核数据路径的 IPsec 隧道（例如 strongSwan 或 Libreswan）。建议不要在终止或路由关键 IPsec 流量的主机上使用此缓解措施。 rxrpc 它是 AF_RXRPC 传输，几乎完全由 AFS 客户端使用，很少出现在 Web 服务器或其他通用场景中。
应用缓解措施后恢复页面缓存
另一个常被忽略的点是，漏洞利用成功时，可能会在内存中留下一些痕迹。 页面缓存中合法二进制文件的修改副本最典型的例子是 /usr/bin/su但是，如果攻击者决定改变目标，其他特权二进制文件可能会受到影响。
因此，一些建议指出，在应用模块黑名单缓解措施后，您应该继续执行以下步骤： 清除系统页面缓存 强制从磁盘重新加载。这可以通过写入来实现。 /proc/sys/vm/drop_caches 此值指示内核释放页面缓存和目录项/inode。此操作仅删除干净页面，因此在生产系统中是安全的，但当再次读取二进制文件和数据时，可能会导致磁盘 I/O 暂时增加。
这个想法很简单：如果 Fragnesia 实例在缓解措施实施之前已经执行过， 损坏的页面将被丢弃，未更改的磁盘版本将再次使用。结合模块黑名单，这一步骤降低了缓存中可能存在的残留修改仍然可被利用或导致系统出现异常行为的风险。
补丁状态和供应商建议
Linux 生态系统中的大多数主要参与者都迅速对 Fragnesia 的发现做出了反应。像 AlmaLinux 和 CloudLinux 这样的发行版已经…… 已发布或正在最终确定已打补丁的内核红帽公司表示，他们正在评估针对先前漏洞的现有缓解措施在多大程度上也适用于 CVE-2026-46300。
包括谷歌和微软相关公司在内的多家安全厂商已发布分析报告，解释道： 该漏洞允许无特权的本地攻击者修改页面缓存中只读文件的内容。 并通过确定性内存损坏提升至 root 权限。例如，Wiz 指出，AppArmor 和对非特权用户命名空间的限制可以部分缓解此漏洞的影响，因为在某些环境下，成功利用该漏洞需要额外的技术。
微软方面则指出： 声明发布时，未发现任何在野外进行的积极捕猎行为。不过，他们仍然敦促用户在补丁发布后立即使用常用的更新工具进行应用。如果无法立即打补丁，他们建议采取与 Dirty Frag 相同的缓解措施：禁用 esp4、esp6 和非必要的 IPsec/XFRM 相关功能，加强交互式本地访问，并强化对异常权限提升活动的监控。
威胁背景：漏洞利用市场和补丁疲劳
弗拉格尼西亚的发现发生在这样的背景下： 利用Linux本地权限提升漏洞进行交易在黑市上越来越有价值。近期报告显示，一名化名为“berz0k”的黑客以170.000万美元的价格出售一个Linux零日本地权限提升漏洞，据称该漏洞可在多个Linux发行版上利用。根据ThreatMon的分析，卖家声称该漏洞属于TOCTOU（Time-of-Check Time-of-Use，检查时间使用时间）类型，允许在不导致系统崩溃的情况下稳定提升权限，并使用共享库形式的有效载荷。.so）部署于 /tmp.
所有这些都加剧了这种感觉。 饱和与疲劳 许多管理员表达了他们的沮丧：“又一个跟Dirty Frag同类的漏洞”，或者“再来八个这样的漏洞我就不干了”，有些人半开玩笑半认真地评论道。事实上，Copy Fail、Dirty Frag和Fragnesia漏洞的接连出现，正迫使系统团队重新思考他们的内核更新策略，尤其是在频繁重启成本极高的环境中。
在这种背景下，像 KernelCare 或类似机制这样的实时修补解决方案正变得越来越重要。 在不中断服务的情况下应用关键修复的替代方案与此同时，发行版面临着尽可能缩短发现漏洞、上游修复发布以及在稳定存储库中提供已修补软件包之间的时间的压力。
最终，Fragenesis 成为了一个案例研究，展示了像 XFRM ESP-in-TCP 这样的专用子系统中的一小段逻辑如何产生影响。 与页面缓存机制和特权二进制文件结合使用，会造成毁灭性后果。密切关注安全警报、邮件列表、分发博客以及 Mattermost 或 X（以前称为 Twitter）等通信渠道，是快速反应并最大限度减少暴露窗口的关键。
Fragnesia 带来的威胁不仅在于它能够通过一条命令授予 root 权限，还在于它展现了现代 Linux 环境对 root 权限的依赖程度。 从内核代码到更新工具和强化策略，构成了一条复杂的信任链。保护措施包括结合官方补丁、充分理解的缓解措施、在适当情况下使用实时补丁解决方案，以及明确的本地访问控制和监控策略，这样一来，此类故障就不会成为整个基础设施的单一故障点。
