Linux漏洞、禁运失效与补丁窗口缩短

# Linux 被入侵、保密机制失效，以及不断缩小的补丁窗口期——AskBaize 来源：https://www.askbaize.com/blog/linux-compromises-broken-embargoes-and-the-shrinking-patch-window *作者：**张提** (https://www.linkedin.com/in/ti-zhang/)* *20260503* 2026 年 5 月，两周内连续爆出三个严重的 Linux 本地权限提升漏洞。它们涉及不同的子系统和利用条件，但呈现出相似的模式。本文涵盖了事件经过、披露模型为何失效、对生产环境的影响，以及防御者现在可以采取的措施。 说明采用面向技术读者的写法，并附有通俗英语部分以帮助社区理解。 *注：不包括 Fragnesia（CVE-2026-46300，当前已分配 ID，但**尚未在 NVD 上填充**(https://nvd.nist.gov/vuln/detail/CVE-2026-46300%5D)），该漏洞在本文章发布时被披露，与 Dirty Frag 属于同一漏洞类别。资源链接附在文末。* ## 事件经过 ### Copy Fail，CVE-2026-31431 (https://nvd.nist.gov/vuln/detail/CVE-2026-31431) #### Copy Fail 通俗解释 - 一个涉及写时复制（COW）行为的 Linux 内核内存管理漏洞 - 程序将内存存储在页面（连续的内存块）中。虽然每个程序都保证拥有自己的私有页面以节省空间，但当多个程序**读取**同一页面时，操作系统不会制作副本。 - 然而，一旦有第二个程序尝试写入或修改该页面，内核就应该制作副本（这就是写时复制），而 Copy Fail 在某些条件下破坏了这一保证。本该隔离的数据可能会被意外修改。 - 用一个类比来帮助理解：想象多家公司共享一本严格只读的规则手册以节省空间。一名员工需要将某一页翻译成秘密代码。正常情况下，系统会先制作一份私人影印件。但由于一次有缺陷的效率更新，系统决定直接在原始规则手册上写下翻译，以节省纸张。通过跳过复制步骤来节省资源，系统意外地让一名员工永久覆盖了所有人的规则，彻底破坏了内存隔离。 - 为什么这很可怕？ - 内核内部的隔离失败很危险，因为许多安全边界都依赖它，而内存所有权逻辑中的错误可能成为权限提升的原语 - 与许多竞态条件漏洞相比，该漏洞的利用更加现实，因为它是逻辑相关的，而非时间敏感的 - 攻击者能够在不该写的地方写入时，确实会“加速行动”。 #### Copy Fail 技术解释 - `algif_aead` 中的逻辑缺陷——2017 年的原地 AEAD 优化将 `req->src = req->dst` 设置，使得 `splice()` 支持的页缓存页面能够进入输出 scatterlist；在 `authencesn` 标签重排期间，一个 4 字节的临时写入操作会落入被 splice 的文件缓存页面中 - 无竞态条件，无需 CAP，无需 `algif_aead` 之外的内核模块 - 732 字节 Python PoC (https://xint.io/blog/copy-fail-linux-distributions)，已在 Ubuntu 24.04、RHEL 10.1、Amazon Linux 2023、SUSE 16 上确认获取 root 权限 - 影响内核版本 4.14 至 6.19.11 / 6.18.21（回归引入提交 `72548b093ee3`，修复提交 `fafe0fa2995a`） - 已添加至 CISA KEV (https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog)。确认已在野被积极利用。 #### Copy Fail 披露过程 - 由 Theori / Xint (https://xint.io/) 通过 AI 辅助扫描 `linux/crypto/` 发现（Xint 分析文章 (https://xint.io/blog/copy-fail-linux-distributions)），并在公开发布前约 5 周报告给 Linux 内核安全团队。 - Theori 控制了披露日期，因此并非保密协议被破坏。他们选择在 2026 年 4 月 29 日发布，此时尚未所有发行版都已推送补丁。 - 可利用性：732 字节 Python 脚本，无需编译，在所有受影响发行版上无需修改即可运行。 - 披露时，Arch Linux、Fedora 和 Amazon Linux 已有补丁。SUSE、Red Hat 和 Ubuntu 仅有缓解指南，无修补内核。 - Theori 在披露时指出，他们的扫描在同一内核区域发现了其他高危漏洞，这些漏洞当时仍处于私下负责任披露阶段。 - 临时缓解措施（`algif_aead` 禁用列表）在之后的几天内被广泛部署。 --- ### Dirty Frag，CVE-2026-43284 (https://nvd.nist.gov/vuln/detail/CVE-2026-43284)+CVE-2026-43500 (https://www.openwall.com/lists/oss-security/2026/05/07/8) #### Dirty Frag 通俗解释 - 一个 Linux 内核页缓存/内存片段重用漏洞 - 内核在它没有写入权限的内存页面上执行原地加密操作。当这些页面最初通过 `splice()` 传送时，它们仍然是属于管道的活动管道页面。内核跳过了本应首先制作私有副本的步骤。结果是意外写入操作落入了攻击者选择的文件的页缓存中 - 管道：内核管理的缓冲区，连接两个进程 - `splice()` 是一个系统调用，用于在管道和文件描述符之间移动数据，而不通过用户空间复制 - 攻击者通过控制 splice 操作的位置来选择目标——这不是对任意缓存数据的写入，而是写入攻击者针对的特定文件，包括他们只有读权限的文件。 - 类比帮助理解：想象一间重复使用纸质工单的办公室。当有新任务时，经理分发一张表格，但该表格在物理上仍然附着在前一位工人的发件箱上。新工人填写时，墨水会自动渗透到前一位工人的副本上。连接从未断开——共享页面引用才是问题，而非遗忘的擦除。残留的所有权变成了一个活跃的写入通道。 - 为什么这很可怕？ - 页缓存损坏漏洞对攻击者来说极其宝贵。它们可能影响攻击者可以读取但不应该修改的二进制文件、配置和保护文件。 - 写入操作对磁盘完整性工具不可见。IMA、dm-verity 和磁盘校验和操作的是存储的文件，而不是页缓存。一个被 Dirty Frag 修改的二进制文件将从受损的内存缓存中执行——磁盘上经过验证的副本从未被触及。 - 涉及缓存文件数据的漏洞通常比堆损坏更容易武器化，因为它们绕过了关于只读文件的假设，无需单独的泄露原语或 `KASLR 打破`。 - KASLR（内核地址空间布局随机化）会在每次启动时将内核加载到内存中的地址随机化。每个函数、变量和数据结构都位于不同的地址。想要覆盖特定内核值的攻击者首先需要知道其当前地址。打破 KASLR 意味着要从非特权进程中找到一种读取内核地址的方法。 - Copy Fail 和 Dirty Frag 的可怕之处在于你不需要知道任何内核地址：你的目标是文件路径（`/usr/bin/su`、`/etc/passwd`），而不是内核指针。页缓存是通过文件和偏移量索引的——两者你作为非特权用户都可以控制。无需地址泄露，无需打破 KASLR，无需正确喷射。你选择文件，选择字节偏移，然后写入。这就是为什么此类别漏洞与 ZCRX 处于不同的威胁层级，后者的完整利用链恰恰因为 KASLR 打破是一个棘手且未解决的步骤而停滞。 - 历史上，此类漏洞产生了非常实用的权限提升利用（Dirty Pipe (https://nvd.nist.gov/vuln/detail/CVE-2022-0847)，Dirty COW (https://nvd.nist.gov/vuln/detail/CVE-2016-5195)，OverlayFS PE (https://nvd.nist.gov/vuln/detail/CVE-2021-3493)，Dirty Cred (https://www.google.com/search?q=https://www.blackhat.com/us-22/briefings/schedule/%23dirtycred-escalating-privilege-in-linux-kernel-27156)） #### Dirty Frag 技术解释 - `esp_input` 和 RxKAD 验证路径都接收来自 `splice()` 的 `skb`，这些 skb 的片段页面由内核不拥有的管道页面支持。两者在原地加密之前都跳过了 `skb_cow_data()`，直接写入片段页面，并产生对 splice 文件页缓存的未授权写入。 - 确定性逻辑错误——无竞态条件，无需喷射，无需打破 KASLR，失败时不会导致内核恐慌。目标是文件路径和字节偏移，两者均由攻击者控制。可靠性高。 - 单个二进制 C PoC (https://github.com/V4bel/dirtyfrag)，在所有主要发行版上立即获得 root 权限；`algif_aead` 禁用（Copy Fail 缓解措施）并不阻止此路径 - 已测试：Ubuntu 24.04、RHEL 10.1、Fedora 44、openSUSE Tumbleweed、CentOS Stream 10、AlmaLinux 10 - 运行后：页缓存被污染——需要执行 `echo 3 > /proc/sys/vm/drop_caches` 或重启；磁盘副本未被触及，IMA/dm-verity 对修改无感。 - **CVE-2026-43284**——xfrm ESP 输入（`esp_input`）- IPv4/IPv6 数据报 splice 路径在 UDP skb 上省略了 `SKBFL_SHARED_FRAG`；如果没有设置此标志，ESP 快速路径会将 skb 视为可安全进行原地解密——跳过 `skb_cow_data()`，因为它没有看到 frag_list 和未克隆的 skb，但没有检查片段页面是否为管道所有 - 对非所有权的管道页面进行解密，将加密输出写入 splice 文件的页缓存 - 需要非特权用户命名空间；被 Ubuntu 上的 AppArmor 用户命名空间限制阻止 - 引入：`cac2661c53f3`（2017-01-17，约 9 年暴露时长）；补丁：`f4c50a4034e6` - NVD 引用指向稳定回溯提交；主线修复为 `f4c50a4034e6` - **CVE-2026-43500**——RxRPC / RxKAD 验证路径 - 对 splice 源片段进行原地解密而无需 COW；无需用户命名空间，权限门槛低于 CVE-2026-43284 - `rxrpc.ko` 在大多数发行版上默认未加载；Ubuntu 自动加载它，使得 RxRPC 路径成为 AppArmor 阻止 ESP 路径时的通用回退 - 链条逻辑：ESP 路径覆盖非 Ubuntu（用户命名空间开放）；RxRPC 路径覆盖 Ubuntu（`rxrpc.ko` 自动加载，用户命名空间无关）——盲区相互抵消，通用 LPE - 引入：`2dc334f1a63a`（2023-06-08，约 3 年暴露时长）；补丁：`aa54b1d27fe0` - RxKAD 验证路径中的具体符号未确认——在引用前请对照 `aa54b1d27fe0` diff 验证。 #### Dirty Frag 披露过程 - 由 Hyunwoo Kim（@v4bel）(https://x.com/v4bel) 发现，并于 2026 年 4 月 30 日私下报告给 Linux 维护者。 - Linux 发行版保密协议定于 5 月 12 日，但在补丁或 CVE 存在之前就被外部打破 - 5 月 7 日，一个无关的第三方独立发布了可工作的 exploit，并在 oss-security (https://www.openwall.com/lists/oss-security/2026/05/07/12)、分析文章 (https://afflicted.sh/blog/posts/copy-fail-2.html) 以及 GitHub PoC (https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo) 上提供了完整解释 - 该可工作的 exploit 是通过逆向工程从公开可用的修复提交 `f4c50a4034e6`（位于 `netdev/net.git` 上）得出的 - 第二个独立的 PoC "Copy Fail 2: Electric Boogaloo" (https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo/tree/main) 以相同的路径在同一时间附近公开发布。 - `_SiCk` 在 oss-security (https://www.openwall.com/lists/oss-security/2026/05/07/12) 上澄清：“这项工作是从公共上游提交进行的 n-day 武器化，这是安全相关修复落入公共树后的标准做法”，并直接向 Hyunwoo Kim 道歉。 - Kim 在 oss-security 上写道：*“由于保密协议已被打破，目前不存在补丁或 CVE”*，并咨询了 `[email protected]`。应维护者要求，他在同一天发布了完整的分析文章和 PoC - 披露时，没有补丁，没有 CVE。这比 Copy Fail 的披露状态要糟糕得多。 - CVE 是事后分配的（CVE-2026-43284（ESP）和 CVE-2026-43500（RxRPC）于 5 月 8 日分配）。 - AlmaLinux 和 Ubuntu 在 5 月 8 日前推送了修补内核；RHEL、SUSE、Debian、Fedora 确认收到并正在制作补丁。 --- ### io_uring ZCRX freelist OOB write (https://ze3tar.github.io/post-zcrx.html),CVE-2026-43121 (https://app.opencve.io/cve/CVE-2026-43121) #### io_uring ZCRX freelist OOB write 通俗解释 - 由于两个 CPU 核心同时尝试清理同一件事物，导致记账失败。内核意外地释放了同一对象两次，其内部回收列表随之损坏。最终内核将数据写入了本不应使用的内存区域之外。 - 该内存损坏有可能被转化为权限提升，尽管目前不存在完全可工作的公开利用链。易受攻击的代码是 `io_uring` 的一部分，这是一个用于极快网络和存储操作的高性能 Linux I/O 系统。涉及的具体特性称为 ZCRX（“零拷贝接收”）。 - 零拷贝系统的理念是避免在内存中不断地复制数据，而是重用现有缓冲区，从而提高性能并降低 CPU 开销。 - 这对速度有好处，但使内存所有权跟踪变得复杂。 - 类比帮助理解：一家租车公司有两名职员。如果有人用完了一辆租车，职员 A 在系统中登记“嘿，有一辆新车可供出租”（CPU0 看到 count=1，释放对象）。由于某种错误，职员 B 也将同一辆车登记到系统中（CPU1 看到 count=1，释放同一对象）。现在公司的系统认为有 +2 辆车可供出租，而不是 +1（内核意外地将同一对象两次放入可重用对象列表）- 那个可重用列表最终会损坏，因为内核认为它拥有的空闲对象比实际多（租车公司认为它有更多可供出租的车辆）。然后内核会写入内部数组的末尾之后（OOB，越界写入）。 - 攻击者可以通过在损坏区域旁边放置一个重要的内核对象来利用它，以有用的方式损坏它，并逐步转化为更多控制（堆整理、slab 放置、对象喷射）。当研究人员谈到这一点时，你可能会听到“受控内存布局操作”这样的说法。 - 这没有 Dirty Frag 或 Copy Fail 那么可怕 - Dirty Frag/Copy Fail（Dirty Pipe 系列）是确定性的，容易可靠触发，并绕过了 KASLR 打破 - io_uring ZCRX freelist OOB（我觉得如果再让我打一次这个计算机恶魔咒语，我就给自己点含真正糖分的汽水）更难利用，因为它依赖时序，并且多个 CPU 核心必须以精确的方式竞速。损坏原语更弱，目前不存在完整的公开 root exploit。 - 该漏洞需要 `CAP_NET_ADMIN`，这是一个有特权的 Linux 能力，用于特殊的网络软件。因此，如果攻击者拥有 `CAP_NET_ADMIN`，你已处于危险之中。 - 现实风险领域包括特权容器、权限过度的 Kubernetes 工作负载、网络工具、可观测性代理、服务网格组件等。 #### io_uring ZCRX freelist OOB write 技术解释 - 与 Copy Fail 和 Dirty Frag 类别不同（无页缓存写入原语、无 COW 绕过、无 splice 参与）。非确定性，需要 SMP 上的时序窗口。 - 严重性低于 Copy Fail 和 Dirty Frag。 - SMP 竞态条件 → 二次释放 → 堆 OOB 写入相邻 slab 对象。 - 完整的利用链（二次释放 → slab 损坏 → KASLR 打破 → `modprobe_path` 覆盖 → uid=0）在撰写本文时尚未公开演示。 - `io_zcrx_put_niov_uref()` 实现了对 `user_refs` 的非原子“检查再递减”操作：`atomic_read()` 时...