tttrove 笔记

io_uring ZCRX Freelist：Linux 内核零拷贝接收路径释放后重用提权漏洞（CVE-2026-43121）

Properties1
tagslinux内核, 提权漏洞, cve-2026-43121, io_uring, zcrx, uaf, 安全研究

16分钟阅读

io_uring ZCRX Freelist：Linux 内核零拷贝接收路径释放后重用提权漏洞

文档版本：v1.0 · 更新日期：2026-05-18 适用对象：安全研究员、系统管理员、DevSecOps 团队

漏洞速览

属性值
CVE 编号CVE-2026-43121
漏洞别名io_uring ZCRX freelist
CVSS 评分7.8 HIGH [待验证]
CVSS 向量AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H [待验证]
漏洞类型CWE-416 Use-After-Free / CWE-415 Double Free
攻击向量本地 (Local)
权限要求低权限 (Low)
用户交互不需要 (None)
公开日期2026-05 [待验证]
PoC 状态未知 [待验证]
补丁版本主线修复中 [待验证]
临时缓解可禁用 io_uring

关键时间线：2026 年 5 月漏洞披露窗口期，CVE-2026-43121 被公开。该漏洞影响启用 io_uring ZCRX（Zero Copy Receive）特性的 Linux 内核版本，目前主线补丁正在开发中，各大发行版尚未发布安全公告 [待验证]。

漏洞简介

Linux 内核 6.15 在 io_uring 子系统中引入了零拷贝接收（Zero Copy Receive, ZCRX）支持，该特性允许网络数据直接从网卡接收至应用程序预先注册的用户态内存缓冲区，彻底跳过内核态的一次数据拷贝，从而显著提升高性能网络应用的吞吐量与延迟表现。然而，ZCRX 路径中的空闲链表（freelist）管理逻辑存在缺陷，在特定并发场景下可能导致已释放的内存页被继续引用。

该漏洞的本质在于 ZCRX 的 freelist 维护了可供复用的用户态缓冲区页面集合。当并发执行零拷贝接收操作时，freelist 的分配与回收路径未正确同步，导致同一物理页面可能被重复释放（Double Free），或是在释放后仍被另一条执行路径通过悬垂指针访问（Use-After-Free）。由于触发的是一般性内存破坏，攻击者可利用这两个漏洞原语实现任意内核内存读写。

当被释放的页面被内核页分配器重新分配给其他内核数据结构（如 slab 缓存中的关键对象）后，攻击者可通过精心构造的数据填充被释放区域（即 Heap Spray），覆盖目标结构的关键字段——例如文件操作表（file_operations）指针、进程凭证（cred）结构等，最终劫持控制流实现权限提升。该漏洞位于 io_uring ZCRX 的优化路径中，而非核心数据通路，因此在普通 io_uring 使用场景下不易触发，但一旦被定向利用，后果严重。

技术原理

攻击链（Exploit Chain）：

  1. 环境准备：创建 io_uring 实例，配置并注册 ZCRX 所需的用户态缓冲区池（buffer ring），使能零拷贝接收能力。
  2. 触发零拷贝接收：通过 io_uring 提交 ZCRX 类型的网络接收请求（如 IORING_OP_RECV_ZC 或等效的 ZCRX 操作码），驱动内核进入 ZCRX 数据路径。
  3. Freelist 管理错误：在并发接收或缓冲区回收过程中，freelist 的分配/释放逻辑存在竞态条件或计数错误，导致某物理页面在仍被引用时被回收到 freelist 或被重复释放。
  4. UAF / Double Free 原语：攻击者获得一个内核层面的 UAF 或 Double Free 原语——前者指向一块已释放但仍可访问的内核内存，后者允许将同一页面两次归还给页分配器。
  5. Heap Spray 占位：利用内核堆喷（Heap Spray）技术，通过大量分配特定大小的内核对象（如 msg_msg、pipe_buffer、shm_file_data 等），占据被释放页面的内存位置，将可控数据写入。
  6. 覆写关键内核结构：通过 UAF 指针或 Double Free 后的碰撞写入，覆写目标内核结构——典型目标为 file_operations 函数指针表、task_struct->cred、modprobe_path 等。
  7. 触发权限提升：调用被篡改后的内核路径（例如对被覆写 file_operations 的文件执行 read()/ioctl() 等系统调用），使内核跳转至攻击者控制的函数指针，执行 commit_creds(prepare_kernel_cred(0)) 获得 root 权限。

涉及核心组件：

组件作用
io_uring ZCRX零拷贝接收机制，提供从网卡到用户态缓冲区的直接数据传输
Freelist管理可复用的用户缓冲区页面，维护分配/回收状态
页分配器（Page Allocator）内核伙伴系统，负责物理页面的分配与回收
内核堆喷（Kernel Heap Spray）利用内核对象分配行为，精确占据释放后的内存区域
file_operations文件操作函数指针表，是内核漏洞利用的经典控制流劫持目标

受影响版本

产品 / 组件受影响版本修复版本备注
Linux Kernel（ZCRX 已启用）>= 6.15 [待验证]待确认 [待验证]ZCRX 在 6.15 版本中引入，受影响范围从该版本起
Linux Kernel（< 6.15）不适用不适用ZCRX 特性不存在，不受此漏洞影响

注意：即使运行 Linux 6.15 及以上版本，如果未配置 CONFIG_IOURING_ZCRX 或在运行时不使用 ZCRX 功能，实际风险会大幅降低。但建议仍视为受影响并采取缓解措施，因为内核模块的存在本身即构成攻击面。

漏洞影响场景

  1. 高性能服务器本地提权（LPE）
    使用 io_uring ZCRX 进行网络 I/O 加速的高性能服务器（如 HTTP 代理、消息队列、流媒体服务）面临本地低权限用户提权至 root 的风险。攻击者仅需在目标主机上拥有普通用户 shell 即可发起利用。

  2. 容器逃逸
    在容器环境中，如果容器被授予访问 io_uring 的能力（未通过 seccomp 限制 io_uring_setup / io_uring_enter 等系统调用），容器内攻击者可通过该漏洞突破容器隔离，获取宿主机 root 权限，进而控制整个节点。

  3. 云平台 / Kubernetes 节点沦陷
    在多租户 Kubernetes 集群中，若节点内核版本 >= 6.15 且未禁用 io_uring，任一 Pod 内的攻击者在获得代码执行能力后即可利用此漏洞逃逸至节点层面，危及同节点上其他租户的工作负载。

  4. 数据库 / 存储系统攻击面
    一些现代数据库和存储引擎（如 ScyllaDB、Ceph 的部分组件）深度依赖 io_uring 进行高性能 I/O。若这些系统所在主机暴露了本地访问入口（如共享托管环境、运维终端），攻击者可利用该漏洞突破数据库进程的权限边界。

修复措施

推荐修复（根本解决）

在官方补丁发布后，立即将内核升级至包含修复的版本。具体步骤：

  • 关注 kernel.org 主线以及所用发行版的安全公告（Red Hat、Ubuntu、Debian、SUSE、Amazon Linux 等）。
  • 待发行版推送修复内核包后，执行系统更新：
    • Ubuntu / Debian：sudo apt update && sudo apt upgrade
    • RHEL / CentOS / Fedora：sudo dnf update kernel*
    • Arch Linux：sudo pacman -Syu
  • 更新后重启系统加载新内核，并验证 uname -r。

临时缓解（无法立即升级时）

在补丁可用之前，推荐通过 sysctl 参数禁用 io_uring：

# 完全禁用 io_uring（所有用户均不可用）
sudo sysctl -w kernel.io_uring_disabled=2
 
# 或限制为仅 CAP_SYS_ADMIN 权限用户可用
sudo sysctl -w kernel.io_uring_disabled=1

写入持久化配置（重启后保持生效）：

echo "kernel.io_uring_disabled=2" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

副作用评估：禁用 io_uring 会影响依赖该机制的应用程序，包括但不限于 ScyllaDB、部分 Ceph 配置、高性能网络代理等。在部署前请确认业务应用对 io_uring 的依赖情况。若业务关键应用依赖 io_uring，建议与业务方评估后采用白名单策略或尽快协调升级窗口。

一键检查与执行临时修复脚本

检查脚本

#!/bin/bash
# check_cve_2026_43121.sh
# 检查当前系统是否可能受 CVE-2026-43121 影响
 
set -e
 
echo "============================================="
echo " CVE-2026-43121 影响评估检查"
echo " io_uring ZCRX Freelist UAF/Double Free"
echo "============================================="
echo ""
 
# 1. 检查内核版本
KERNEL_VER=$(uname -r)
echo "[1] 当前内核版本: $KERNEL_VER"
 
MAJOR=$(echo "$KERNEL_VER" | cut -d. -f1)
MINOR=$(echo "$KERNEL_VER" | cut -d. -f2)
 
if [ "$MAJOR" -gt 6 ] || { [ "$MAJOR" -eq 6 ] && [ "$MINOR" -ge 15 ]; }; then
    echo "    ⚠ 风险: 内核版本 >= 6.15，可能受漏洞影响"
    AFFECTED=1
else
    echo "    ✓ 内核版本 < 6.15，不受此漏洞影响"
    AFFECTED=0
fi
 
# 2. 检查 io_uring 状态
echo ""
echo "[2] io_uring 状态检查"
 
if [ -f /proc/sys/kernel/io_uring_disabled ]; then
    IO_URING_STATE=$(cat /proc/sys/kernel/io_uring_disabled)
    case "$IO_URING_STATE" in
        0) echo "    ⚠ io_uring 已启用（对所有用户开放）" ;;
        1) echo "    ⚠ io_uring 已启用（仅 CAP_SYS_ADMIN 可用）" ;;
        2) echo "    ✓ io_uring 已完全禁用" ;;
        *) echo "    ? 未知状态: $IO_URING_STATE" ;;
    esac
else
    echo "    ? 无法读取 /proc/sys/kernel/io_uring_disabled（内核可能不支持该参数）"
fi
 
# 3. 检查 io_uring 相关内核模块
echo ""
echo "[3] io_uring 模块加载情况"
if lsmod 2>/dev/null | grep -q io_uring; then
    echo "    ⚠ io_uring 模块已加载"
else
    echo "    ✓ io_uring 模块未加载（或已编译进内核）"
fi
 
# 4. 检查 CONFIG_IOURING_ZCRX（从内核配置文件）
echo ""
echo "[4] ZCRX 编译配置检查"
if [ -f "/boot/config-${KERNEL_VER}" ]; then
    if grep -q "CONFIG_IOURING_ZCRX=y" "/boot/config-${KERNEL_VER}"; then
        echo "    ⚠ CONFIG_IOURING_ZCRX=y — ZCRX 已编译进内核"
    elif grep -q "CONFIG_IOURING_ZCRX=m" "/boot/config-${KERNEL_VER}"; then
        echo "    ⚠ CONFIG_IOURING_ZCRX=m — ZCRX 编译为模块"
    else
        echo "    ✓ CONFIG_IOURING_ZCRX 未设置或为 n"
    fi
elif [ -f "/proc/config.gz" ]; then
    if zcat /proc/config.gz 2>/dev/null | grep -q "CONFIG_IOURING_ZCRX=[ym]"; then
        echo "    ⚠ ZCRX 已启用"
    else
        echo "    ✓ ZCRX 未启用"
    fi
else
    echo "    ? 未找到内核配置文件，无法判断 ZCRX 状态"
fi
 
# 5. 综合评估
echo ""
echo "============================================="
if [ "$AFFECTED" -eq 1 ] && [ "$IO_URING_STATE" != "2" ]; then
    echo " 结论: ⚠ 系统可能受 CVE-2026-43121 影响!"
    echo " 建议: 立即运行临时修复脚本或升级内核"
else
    echo " 结论: ✓ 当前风险较低或已缓解"
fi
echo "============================================="

临时修复脚本

#!/bin/bash
# fix_cve_2026_43121.sh
# 临时禁用 io_uring 以缓解 CVE-2026-43121
 
set -e
 
echo "============================================="
echo " CVE-2026-43121 临时修复"
echo " 禁用 io_uring (kernel.io_uring_disabled=2)"
echo "============================================="
echo ""
 
# 确保以 root 运行
if [ "$(id -u)" -ne 0 ]; then
    echo "错误: 此脚本需要 root 权限运行"
    exit 1
fi
 
CONF_FILE="/etc/sysctl.conf"
BACKUP_FILE="/etc/sysctl.conf.bak_cve_2026_43121_$(date +%Y%m%d_%H%M%S)"
 
# 1. 备份当前 sysctl 配置
echo "[1] 备份 sysctl 配置..."
cp -f "$CONF_FILE" "$BACKUP_FILE"
echo "    备份已保存至: $BACKUP_FILE"
 
# 2. 记录当前 io_uring 状态（用于回滚）
echo ""
echo "[2] 记录当前 io_uring 状态..."
if [ -f /proc/sys/kernel/io_uring_disabled ]; then
    ORIG_STATE=$(cat /proc/sys/kernel/io_uring_disabled)
    echo "    当前状态: $ORIG_STATE (0=启用, 1=受限, 2=禁用)"
else
    ORIG_STATE="unknown"
    echo "    当前状态: 未知"
fi
 
# 3. 立即生效
echo ""
echo "[3] 立即禁用 io_uring..."
sysctl -w kernel.io_uring_disabled=2
echo "    io_uring 已即时禁用"
 
# 4. 持久化配置
echo ""
echo "[4] 持久化配置（重启后保持）..."
if grep -q "^kernel.io_uring_disabled" "$CONF_FILE"; then
    # 已存在配置行，替换
    sed -i "s/^kernel.io_uring_disabled=.*/kernel.io_uring_disabled=2/" "$CONF_FILE"
    echo "    已更新 $CONF_FILE 中的 kernel.io_uring_disabled=2"
else
    # 不存在，追加
    echo "kernel.io_uring_disabled=2" >> "$CONF_FILE"
    echo "    已追加 kernel.io_uring_disabled=2 到 $CONF_FILE"
fi
 
# 5. 验证
echo ""
echo "[5] 验证..."
CURRENT_STATE=$(cat /proc/sys/kernel/io_uring_disabled)
if [ "$CURRENT_STATE" == "2" ]; then
    echo "    ✓ 验证通过: io_uring 已完全禁用"
else
    echo "    ⚠ 验证异常: 当前状态为 $CURRENT_STATE，预期为 2"
fi
 
# 6. 输出摘要
echo ""
echo "============================================="
echo " 修复完成"
echo "============================================="
echo ""
echo "操作摘要:"
echo "  - 原始 io_uring 状态: $ORIG_STATE"
echo "  - 当前 io_uring 状态: $CURRENT_STATE"
echo "  - 备份文件: $BACKUP_FILE"
echo "  - 配置文件: $CONF_FILE (kernel.io_uring_disabled=2)"
echo ""
echo "回滚方法:"
echo "  sudo cp $BACKUP_FILE $CONF_FILE && sudo sysctl -p"
echo "  或手动执行: sudo sysctl -w kernel.io_uring_disabled=0"
echo ""
echo "注意: 如果业务应用依赖 io_uring，禁用后可能出现以下影响:"
echo "  - ScyllaDB / Seastar 框架应用无法启动"
echo "  - 部分 Ceph 组件 I/O 性能下降"
echo "  - 使用 io_uring 的自定义网络服务异常"
echo "  请确认业务影响后再执行修复。"
echo ""

参考资源

资源链接状态
NVD 漏洞详情https://nvd.nist.gov/vuln/detail/CVE-2026-43121待填充 [待验证]
MITRE CVE 页面https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43121待填充 [待验证]
Linux 内核主线提交记录https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git修复补丁待回溯 [待验证]
各发行版安全公告汇总Red Hat / Ubuntu / Debian / SUSE / Amazon Linux 安全页面待发布 [待验证]
io_uring ZCRX 设计文档https://kernel.org/doc/html/latest/filesystems/io_uring.htmlZCRX 文档可能尚未完整合并 [待验证]
Linux 内核 io_uring 禁用 sysctl 说明https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.htmlkernel.io_uring_disabled 参数说明 [待验证]

免责声明：由于 CVE-2026-43121 为 2026 年新公开的漏洞，当前公开资料有限。本文档中的技术细节、影响范围、CVSS 评分及 PoC 可用性均标注为 [待验证]。建议持续关注 NVD、各 Linux 发行版安全公告及内核主线邮件列表（LKML）以获取最新、权威的信息。

关系图谱