Hacker News 中文摘要

RSS订阅

你给我一个u32，我还你root权限。（io_uring ZCRX freelist本地提权漏洞） -- You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

原文链接 | HN讨论 | 2026-05-09 08:29:56

文章摘要

文章披露了Linux内核6.15-6.19版本中iouring的ZCRX零拷贝接收子系统存在高危漏洞。该漏洞由于未对空闲列表计数器进行边界检查，导致可触发4字节越界写入。攻击者通过精心构造的内存布局，能将小整数写入转化为权限提升，最终获取root权限。漏洞影响需启用ZCRX配置并具备CAPNET_ADMIN权限的系统。

文章总结

文章标题：

《从u32到root权限：io_uring ZCRX freelist本地提权漏洞分析》

主要内容概述：

本文详细分析了Linux内核6.15版本引入的io_uring零拷贝接收子系统（ZCRX）中的一个高危漏洞（CVE待分配）。攻击者可通过精心构造的堆布局，利用未初始化的引用计数和双重释放机制，最终实现从普通用户到root权限的提权（LPE）。以下是核心要点：

漏洞本质

  1. 问题根源

    • ZCRX的freelist管理存在缺陷：free_count变量无上限检查，且两个独立的销毁路径（正常释放和强制回收）可能重叠，导致free_count超出预分配数组长度。
    • 结果：触发4字节越界写入（OOB Write），写入值为0到N-1的整数（N由用户控制的num_niovs决定）。

  2. 关键触发条件

    • 内核版本：6.15–6.19（未包含修复提交770594e）。
    • 需启用CONFIG_IO_URING_ZCRX配置（目前主流发行版默认未启用）。
    • 需要真实支持ZCRX的网卡（如Mellanox ConnectX-6+、Intel E800）及CAP_NET_ADMIN权限。

漏洞利用链

步骤一：触发OOB写入

  • 用户空间操作：
    1. 注册ZCRX区域（通过IORING_REGISTER_ZCRX_IFQ），选择num_niovs=32使freelist分配在kmalloc-128缓存。
    2. 发送大量UDP包填充niov池，部分通过正常路径释放，部分保留为“飞行中”状态。
    3. 关闭网卡（SIOCSIFFLAGS ~IFF_UP）触发双重计数，导致freelist[32]越界写入。

步骤二：堆风水（Heap Feng Shui）

  • 目标对象：
    通过msgsnd()喷射kmalloc-128的msg_msg结构体，使其相邻于freelist。OOB写入会修改msg_msg.m_list.next的低4字节，将其指向可控的堆地址。
  • 信息泄露：
    利用被篡改的msg_msg，通过msgrcv(MSG_COPY)读取相邻内核内存，泄露KASLR偏移和modprobe_path地址。

步骤三：权限提升

  1. 篡改modprobe_path：
    通过/proc/sys/kernel/modprobe将路径指向恶意脚本（需CAP_SYS_ADMIN权限，通常与CAP_NET_ADMIN共存于容器环境）。
  2. 触发执行：
    创建未知协议族的socket，内核调用call_usermodehelper执行恶意脚本，生成SUID root shell。

技术细节

  • OOB写入限制：
    写入值为小整数（0–31），但通过选择num_niovs可控制目标slab缓存（如kmalloc-128）及相邻对象类型。
  • 绕过防护机制：
    SMEP/SMAP无效（无用户空间代码执行），KASLR通过堆泄露绕过，KASAN仅在调试内核中生效。

修复方案

提交770594e（2026年4月21日）添加了边界检查：
c if (WARN_ON_ONCE(area->free_count >= area->nia.num_niovs)) return;

影响范围

  • 典型场景：
    Kubernetes网络插件、Docker容器（--cap-add NET_ADMIN）、具备网络管理权限的虚拟机或本地用户。
  • PoC验证：
    作者提供了崩溃触发（zcrx_crash.c）和完整提权（zcrx_lpe.c）的代码示例。

总结

该漏洞展示了如何将看似无害的4字节小整数写入转化为完整的权限提升链，凸显了内核内存管理的细微缺陷可能导致的严重后果。管理员应关注相关修复补丁，并限制CAP_NET_ADMIN权限的分配。

评论总结

以下是评论内容的总结：

  1. 对Linux安全性的担忧

    • 观点：认为Linux系统安全问题频发，修复速度跟不上漏洞发现速度。
    • 引用：
      • "Linux is falling apart faster than it can assign these CVEs." (rvz)
      • "I've never seen these many security/incident related posts on HN's front page." (rishabhaiover)

  2. 对io-uring安全性的批评

    • 观点：io-uring存在严重安全问题，建议禁用。
    • 引用：
      • "io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling." (staticassertion)
      • "Do most servers need this? Or can most of us 'sysctl -w kernel.iouringdisabled=2'?" (SubiculumCode)

  3. 对漏洞严重性的争议

    • 观点：部分用户认为漏洞实际影响有限，需特定权限或条件才能利用。
    • 引用：
      • "CAPNET/SYSADMIN is required for this. So this would be 'not as bad' as the others." (kro)
      • "If you can write modprobe_path, is it really news that you can find a way to execute code?" (stonegray)

  4. 对漏洞修复和公开的讨论

    • 观点：部分用户质疑漏洞是否为新问题，并讨论修复状态。
    • 引用：
      • "Jens seems to think that this is already patched and in stable." (FriedFishes)
      • "The title looks like clickbait to me." (csmantle)

  5. 对技术细节的讨论

    • 观点：讨论漏洞的技术细节和潜在攻击方式。
    • 引用：
      • "No bounds check. free_count is incremented before the write..." (saghm)
      • "a 4 byte OOB write is plenty for a data-only attack like [PageJack]." (shorden)

  6. 对公开漏洞数量的担忧

    • 观点：公开漏洞数量引发对未公开漏洞的担忧。
    • 引用：
      • "If this many are public right now, what does that say about the dark matter of private ones?" (ctoth)

  7. 对文章形式的批评

    • 观点：批评文章依赖客户端JavaScript，建议提供静态版本。
    • 引用：
      • "This kind of post really shouldn't require client-side js — from third-party domain — to read..." (pamcake)

总结：评论主要围绕Linux安全性、io-uring漏洞的严重性及修复状态展开，部分用户认为漏洞影响有限，而另一些则对安全问题表示担忧。技术细节和文章形式也引发讨论。