就在大家以为Linux内核的“脏页”系列漏洞（如Dirty Pipe）已成往事时，一个名为 “Dirty Frag” 的新成员，再次以其惊人的破坏力，敲响了警钟。2026年5月8日，韩国安全研究员Hyunwoo Kim公开披露了这一本地提权漏洞链，并附带了PoC代码。由于披露禁令被意外打破，各厂家官方补丁尚未全面发布，导致主流Linux发行版都面临着“裸奔”的风险。

Dirty Frag并非单一漏洞，而是巧妙地串联了两个独立的内核缺陷，允许本地普通用户通过一条简单的命令，稳定、高效地将权限提升至Root权限，且不会导致系统崩溃。它的出现，再次提醒我们，即使是久经考验的Linux内核，也可能在看似无害的“零拷贝”优化中，埋下深层的安全隐患。

本文将带你深入剖析Dirty Frag漏洞的技术原理、危害评估，并提供一份主流 Linux平台应急指南，希望能够帮助大家从容应对Dirty Frag漏洞的冲击，快速加固系统，抵御潜在威胁。

一、漏洞全景：Dirty Frag 的前世今生

1.1 漏洞背景与命名

Dirty Frag 漏洞链由两个独立的 CVE 组成：

  • • CVE-2026-43284：涉及 IPsec ESP (Encapsulating Security Payload) 模块。

  • • CVE-2026-43500：涉及 RxRPC (Remote Procedure Call) 模块。

这两个漏洞的组合利用，使得攻击者能够对内核页缓存进行可控的4字节写入，从而实现本地权限提升。由于其利用方式与Dirty Pipe 家族在页缓存操作上的相似性，故得名“Dirty Frag”。

1.2 关联漏洞家族

Dirty Fra 属于Dirty Pipe漏洞家族的延续，它利用了内核零拷贝路径上的页缓存写入缺陷。与之前的Copy Fail漏洞利用路径完全不同，这意味着即使你的系统已经修复了Copy Fail，依然会受到Dirty Frag的攻击。这充分说明了内核安全领域的复杂性和挑战性。

1.3 当前状态

截至 2026 年5月 10日，主流 Linux 发行版（包括但不限于Ubuntu、RHEL、Debian、OpenEuler、UOS、KylinOS等）中已有厂商发布了修复补丁，大家可以到各自官网查询最新消息，已推出官网补丁的请使用官方补丁进行修复。还未推出官方补丁的，我们必须依靠临时缓解措施来保护系统。

二、技术原理：页缓存的“零拷贝”陷阱

Dirty Frag的核心在于利用Linux内核的页缓存机制。当系统读取文件时，内核会将其缓存在内存中以加速访问。攻击者通过构造特定的网络数据包，利用零拷贝机制，将自己仅有读权限的文件页缓存，映射到内核网络缓冲区中，并最终实现对只读页的写入。

2.1 漏洞链组合

Dirty Frag由两个互补的漏洞组成，实现了对所有主流发行版的“全覆盖”：

  • • xfrm-ESP 页缓存写入漏洞 (CVE-2026-43284)：该漏洞自 2017年1月引入内核，影响范围极广。攻击者利用 IPsec ESP 模块的解密流程，可以对只读页执行原地改写。但其利用需要创建非特权用户命名空间，这在Ubuntu等开启了 AppArmor 严格模式的系统中会被拦截。

  • • RxRPC 页缓存写入漏洞 (CVE-2026-43500)：该漏洞于2023年6月引入，利用RxRPC网络模块的缺陷。其优势在于无需用户命名空间权限即可触发，但大多数发行版默认不加载该模块。然而，Ubuntu 默认加载了 rxrpc 模块，恰好弥补了前一个漏洞的短板，使得攻击链在Ubuntu上更为顺畅。

2.2 利用逻辑

通过串联这两个漏洞，攻击者可以篡改 /etc/passwd 或SUID二进制文件等关键系统文件的页缓存。由于内核在解密流程中会原地改写这些只读页，攻击者便能成功写入恶意数据，从而创建一个拥有Root权限的新用户，完成提权。整个过程稳定、高效，且不依赖竞争条件。

三、危害评估：一行命令的“提权”噩梦

  • • 危害等级：高危。本地普通用户可直接获取Root权限，对系统安全构成严重威胁。

  • • 利用难度：极低。公开的PoC代码使得攻击者只需执行一条命令，即可一键获得 Root Shell。

  • • 稳定性：极高。Dirty Frag是一个纯逻辑漏洞，不依赖竞争条件，首次尝试即可成功，且失败不会导致内核崩溃。

  • • 影响范围：2017年以后主流 Linux 发行版几乎都受到影响，包括但不限于 Ubuntu 24.04.4、RHEL 10.1、CentOS Stream 10、AlmaLinux 10、Fedora 44、openSUSE Tumbleweed 等，内核版本最高波及 7.x。具体受影响的内核版本范围，请参考各发行版官方安全公告。

四、应急指南：主流Linux平台临时解决方案

在官方补丁发布之前，我们需要构建“双重防线”：既要禁用高危模块，又要限制非特权用户创建User Namespace。以下措施均需Root权限执行。

4.1 防线一：禁用高危内核模块（阻断 CVE-2026-43500 及辅助路径）

这是最基础的防御措施，适用于所有发行版。通过将 esp4、esp6 和 rxrpc 模块加入黑名单，阻止它们被加载。

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

说明：

  • • printf 命令将模块禁用规则写入 /etc/modprobe.d/dirtyfrag.conf，确保重启后模块不会被加载。

  • • rmmod 命令尝试卸载当前已加载的模块。2>/dev/null || true 用于抑制错误输出，即使模块未加载也不会报错。

4.2 防线二：限制非特权用户创建 User Namespace（阻断 CVE-2026-43284）

这是针对 xfrm-ESP 漏洞利用链的关键阻断措施。通过设置内核参数，禁止普通用户调用系统调用创建新的用户命名空间。

针对 Debian / Ubuntu / UOS / Deepin
# 1. 立即生效 sudo sysctl -w kernel.unprivileged_userns_clone=0  # 2. 永久生效 (写入配置文件) echo "kernel.unprivileged_userns_clone = 0" | sudo tee /etc/sysctl.d/99-dirtyfrag-userns.conf

说明：

  • • kernel.unprivileged_userns_clone 参数控制非特权用户是否可以创建用户命名空间。设置为 0 则禁止。

  • • /etc/sysctl.d/ 目录下的配置文件会在系统启动时自动加载，实现永久生效。

针对 RHEL / CentOS / Rocky Linux / AlmaLinux / Fedora
# 1. 立即生效 sudo sysctl -w user.max_user_namespaces=0  # 2. 永久生效 (写入配置文件) echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-dirtyfrag-userns.conf

说明：

  • • user.max_user_namespaces 参数限制每个用户（UID）可以创建的用户命名空间（User Namespace）的最大数量。设置为 0 则禁止。

  • • /etc/sysctl.d/ 目录下的配置文件会在系统启动时自动加载，实现永久生效。

4.3 各平台专项说明

  • • RHEL/CentOS/Rocky Linux/AlmaLinux 系列：执行上述两条防线命令。对于内核静态编译了受影响模块的系统，rmmod 命令可能无效，但 modprobe.d 配置依然能阻止模块在下次重启后加载。

  • • Ubuntu/Debian 系列：执行上述两条防线命令。Ubuntu 默认加载 rxrpc 模块且允许非特权用户创建命名空间，因此双重防御尤为重要。

  • • Arch Linux：执行上述两条防线命令。Arch 用户需注意，滚动更新可能尚未包含修复补丁，临时禁用是最佳选择。

  • • OpenSUSE Tumbleweed：执行上述两条防线命令。OpenSUSE Tumbleweed 已确认受影响。

  • • UOS/Deepin 系列：执行上述两条防线命令。UOS 和 Deepin 基于 Debian，其内核版本通常在受影响范围内。

  • • KylinOS（麒麟操作系统）：执行上述两条防线命令。麒麟系统通常用于关键领域，安全要求极高，建议在操作前与业务部门确认是否依赖 IPsec VPN 等功能。

  • • OpenEuler：执行上述两条防线命令。OpenEuler 是华为开源的企业级 Linux 发行版，其内核版本通常在受影响范围内。

五、检测与一键修复脚本：你的“安全管家”

为了方便大家快速排查和修复，我整理了一个升级版的检测与修复脚本。该脚本不仅检查高危模块加载状态，还会检查User Namespace的配置情况，并提供一键修复选项，确保双重防线无遗漏。本文提供的所有信息和脚本仅供参考和学习。在生产环境中执行任何操作前，请务必进行充分的测试和评估，并确保您已了解所有潜在风险。因使用本文内容而导致的任何损失，本文作者及平台概不负责。


#!/bin/bash
# Dirty Frag 漏洞检测与修复脚本 (CVE-2026-43284, CVE-2026-43500)
# 适用于所有主流Linux发行版，包括 RHEL/Rocky/CentOS, Debian/Ubuntu 等
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color
# 检查是否为root用户
if [ "$(id -u)" -ne 0 ]; then
    echo -e "${RED}错误：请使用root权限或sudo运行此脚本${NC}"
    exit 1
fi
echo -e "${BLUE}======================================${NC}"
echo -e "${BLUE}   Dirty Frag 漏洞检测与修复工具     ${NC}"
echo -e "${BLUE}   CVE-2026-43284 / CVE-2026-43500   ${NC}"
echo -e "${BLUE}   微信公众号：运维技术小记          ${NC}"
echo -e "${BLUE}======================================${NC}"
echo ""
# --- 1. 检查模块加载状态 ---
echo -e "${YELLOW}[1/3] 检查高危内核模块加载状态...${NC}"
MODULES_LOADED=0
MODULES_TO_CHECK="esp4 esp6 rxrpc"
for module in $MODULES_TO_CHECK; do
    if lsmod | grep -q "^$module"; then
        echo -e "  ${RED}[警告] 模块 $module 已加载，系统存在风险！${NC}"
        MODULES_LOADED=1
    else
        echo -e "  ${GREEN}[安全] 模块 $module 未加载${NC}"
    fi
done
# --- 2. 检查User Namespace配置 ---
echo ""
echo -e "${YELLOW}[2/3] 检查User Namespace权限配置...${NC}"
# 判断系统类型，采用不同的检查策略
if [ -f /etc/debian_version ] || [ -f /etc/lsb-release ]; then
    # Debian/Ubuntu 系
    UNPRIV_USERNS=$(sysctl -n kernel.unprivileged_userns_clone 2>/dev/null)
    if [ -z "$UNPRIV_USERNS" ]; then
        echo -e "  ${YELLOW}[注意] 系统未设置 kernel.unprivileged_userns_clone 参数${NC}"
        USERNS_RISK=1
    elif [ "$UNPRIV_USERNS" -eq 1 ]; then
        echo -e "  ${RED}[警告] 允许普通用户创建User Namespace，系统存在风险！${NC}"
        USERNS_RISK=1
    else
        echo -e "  ${GREEN}[安全] 已禁止普通用户创建User Namespace${NC}"
        USERNS_RISK=0
    fi
else
    # RHEL/CentOS/Rocky/Fedora 系
    # 在这些系统中，通常通过限制 user.max_user_namespaces 来达到类似效果
    MAX_USERNS=$(sysctl -n user.max_user_namespaces 2>/dev/null)
    if [ -z "$MAX_USERNS" ] || [ "$MAX_USERNS" -gt 0 ]; then
        echo -e "  ${YELLOW}[注意] 未限制用户命名空间数量，建议加固${NC}"
        USERNS_RISK=1
    else
        echo -e "  ${GREEN}[安全] 用户命名空间已受限${NC}"
        USERNS_RISK=0
    fi
fi
# --- 3. 提供修复选项 ---
echo ""
echo -e "${YELLOW}[3/3] 风险评估与修复建议${NC}"
if [ $MODULES_LOADED -eq 1 ] || [ "$USERNS_RISK" -eq 1 ]; then
    echo -e "${RED}系统存在Dirty Frag漏洞风险，建议立即修复！${NC}"
    echo ""
    read -p "是否执行自动修复？(y/n): " -n 1 -r
    echo
    if [[ $REPLY =~ ^[Yy]$ ]]; then
        echo ""
        echo -e "${BLUE}正在执行修复操作...${NC}"
        # 修复1: 禁用高危模块
        if [ $MODULES_LOADED -eq 1 ]; then
            echo -e "${YELLOW}正在禁用高危内核模块...${NC}"
            sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
            rmmod esp4 esp6 rxrpc 2>/dev/null || true
            echo -e "${GREEN}✓ 高危模块已禁用并加入黑名单${NC}"
        else
            # 即使模块未加载，也确保黑名单文件存在，防止未来被加载
            if [ ! -f /etc/modprobe.d/dirtyfrag.conf ]; then
                 echo -e "${YELLOW}模块未加载，但为确保安全，正在创建模块黑名单配置...${NC}"
                 sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
                 echo -e "${GREEN}✓ 模块黑名单配置已创建${NC}"
            else
                 echo -e "${GREEN}✓ 模块黑名单已存在，无需操作${NC}"
            fi
        fi
        # 修复2: 限制User Namespace
        if [ "$USERNS_RISK" -eq 1 ]; then
            echo -e "${YELLOW}正在限制非特权用户创建User Namespace...${NC}"
            if [ -f /etc/debian_version ] || [ -f /etc/lsb-release ]; then
                # Debian/Ubuntu 系
                sysctl -w kernel.unprivileged_userns_clone=0 2>/dev/null || true
                if [ ! -f /etc/sysctl.d/99-dirtyfrag-userns.conf ]; then
                    echo "kernel.unprivileged_userns_clone = 0" > /etc/sysctl.d/99-dirtyfrag-userns.conf
                fi
            else
                # RHEL/CentOS/Rocky/Fedora 系
                sysctl -w user.max_user_namespaces=0
                if [ ! -f /etc/sysctl.d/99-dirtyfrag-userns.conf ]; then
                    echo "user.max_user_namespaces = 0" > /etc/sysctl.d/99-dirtyfrag-userns.conf
                fi
            fi
            echo -e "${GREEN}✓ User Namespace限制已生效${NC}"
        else
            echo -e "${GREEN}✓ User Namespace已受限，无需操作${NC}"
        fi
        echo ""
        echo -e "${GREEN}======================================${NC}"
        echo -e "${GREEN}   修复完成！系统已加固            ${NC}"
        echo -e "${GREEN}   微信公众号：运维技术小记        ${NC}"
        echo -e "${GREEN}======================================${NC}"
        echo ""
        echo -e "${YELLOW}注意：${NC}"
        echo "1. 禁用模块会影响IPsec VPN和AFS文件系统功能"
        echo "2. 限制User Namespace可能影响部分容器应用"
        echo "3. 请重启系统以确保所有更改生效"
    else
        echo -e "${YELLOW}修复已取消，请手动执行以下命令：${NC}"
        echo ""
        echo "# 1. 禁用高危模块"
        echo "sudo sh -c \"printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true\""
        echo ""
        echo "# 2. 限制非特权用户创建User Namespace"
        if [ -f /etc/debian_version ] || [ -f /etc/lsb-release ]; then
             echo "sudo sysctl -w kernel.unprivileged_userns_clone=0"
             echo "echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyfrag-userns.conf"
        else
             echo "sudo sysctl -w user.max_user_namespaces=0"
             echo "echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyfrag-userns.conf"
        fi
    fi
else
    echo -e "${GREEN}系统已进行加固，风险已消除。${NC}"
fi
echo ""
echo -e "${BLUE}=== 检查与修复完成 ===${NC}"

请在linux系统上编辑此脚本，取名例如fix_dirtyfrag.sh，然后+x权限。UOS系统上执行加sudo bash。

脚本网盘链接：

https://pan.baidu.com/s/17tEIZeVSi9fOyopET3jsow?pwd=ciwr

https://pan.quark.cn/s/f6911f396a1a    提取码：kgLA

脚本我在Rocky Linux 9.7、Ubuntu 24.03 sp1、UOS V20 1070上完成验证。

图片

图片

图片

六、写在最后：安全无止境，加固进行时

从Dirty Pipe到Copy Fail，再到如今的Dirty Frag，Linux内核的页缓存机制似乎成了一个“漏洞富矿”。这并非意味着Linux不安全，而是揭示了操作系统在追求极致性能时，所面临的巨大安全挑战。

对于运维人员和安全工程师来说，这无疑是一个必须修复的高危漏洞。但危机也是机遇，它促使我们重新审视自身系统的安全基线，加固每一道防线。记住，没有绝对安全的系统，只有不断进化的防御。

希望本文能为你提供一份及时、准确、有效的应急指南。如果你在修复过程中遇到任何问题，或者有更专业的见解，欢迎在评论区留言讨论。让我们一起，为Linux 的安全生态贡献一份力量！

参考资料：

  • • [1]  https://dirtyfrag.io/

  • • [2] Red Hat Security Advisory for CVE-2026-43284

  • • [3] Debian Security Tracker for CVE-2026-43284

  • • [4] https://almalinux.org/blog/2026-05-07-dirty-frag/

  • • [5] Kernel.org Git Commit for CVE-2026-43284 Patch

# linux # 安全 # 运维
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

动态优先级反转避免：Harness 中的死锁解决方案

本文从经典的优先级反转问题出发，系统解析了静态优先级场景下传统解决方案的局限性，深入拆解了云原生时代动态优先级调度面临的全新挑战，结合CI/CD龙头厂商Harness的工业级落地方案，完整呈现了动态优先级反转避免与死锁解决的技术原理、架构设计、代码实现与最佳实践。全文包含核心概念对比、数学模型推导、算法流程图、可运行的Python实现、真实业务场景案例与未来发展趋势，适合云原生运维工程师、调度系统

avatar AtomGit开源社区

每日 AI 研究简报 · 2026-05-17

AI 正在取代它最需要学习的专家——企业 AI 部署的隐性风险首次被系统建模；tinyhumansai/openhuman 今日再涨 1,549 星突破 11,000 星大关；周末 ArXiv 无新论文（注：ArXiv API 今日出现 429 限流，沿用以往批次）。

avatar AtomGit开源社区
cover

Transformer 的 Encoder 和 Decoder 模块介绍：从结构原理到大模型应用实践

avatar AtomGit开源社区