|
一、漏洞描述 近期，Linux Kernel 被披露存在本地权限提升漏洞，漏洞编号
CVE-2026-43284，代号 “Dirty Frag”。
该漏洞可导致本地低权限用户攻击者通过特定方式实现本地权限提升至 root，多个主流 Linux 发行版均受影响。 二、影响范围 根据公开披露信息，几乎所有主流Linux发行版均受影响，且因系统默认配置问题，除非已部署官方补丁或采取了有效的缓解措施，否则应默认系统存在该漏洞。 三、解决方案 1.首选方案：官方补丁升级 目前主流发行版均已发布内核安全补丁，建议尽快升级内核至修复版本。 2.临时缓解方案： 1. 判断可用的临时缓解方式先根据内核配置确认相关功能是否可以通过模块方式禁用： grep -E 'CONFIG_INET_ESP|CONFIG_INET6_ESP|CONFIG_AF_RXRPC' /boot/config-$(uname -r)
判断方式： ● CONFIG_INET_ESP=m / CONFIG_INET6_ESP=m：esp4 / esp6 以模块形式存在，可以通过 modprobe 黑名单临时禁用，并尝试卸载当前已加载模块。 ● CONFIG_AF_RXRPC=m：rxrpc 以模块形式存在，可以通过 modprobe 黑名单临时禁用，并尝试卸载当前已加载模块。 ● CONFIG_INET_ESP=y / CONFIG_INET6_ESP=y：ESP 功能编译进内核，无法通过 rmmod 或 modprobe 黑名单完全禁用，只能通过升级修复内核、切换不包含该功能的内核，或禁用 user namespace 做辅助降风险。 ● CONFIG_AF_RXRPC=y：RxRPC 编译进内核，无法通过卸载模块方式禁用，应优先升级修复内核或切换不包含该功能的内核。 ● 如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC。很多发行版默认并不会编译 RxRPC，这种情况下无需针对 rxrpc 模块做禁用处置。 2. 排查 user namespace 状态ESP 场景当第 1 节输出 CONFIG_INET_ESP=y 或 CONFIG_INET6_ESP=y，且短期无法升级或切换内核时，可以检查系统是否允许创建 user namespace： cat /proc/sys/user/max_user_namespaces
如果输出为 0，说明系统已经禁止创建 user namespace，这可以降低 DirtyFrag xfrm-ESP 变体被普通本地用户触发的风险。 如果输出大于 0，且业务确认不依赖 user namespace，可以考虑将其设置为 0 作为 ESP 内建场景下的辅助降风险措施。 如业务确认不依赖 user namespace，可以临时禁用： sudo sysctl -w user.max_user_namespaces=0
如需重启后保持生效，可以写入独立 sysctl 配置： echo'user.max_user_namespaces = 0'|sudotee /etc/sysctl.d/99-disable-userns.conf
sudo sysctl --system
ESP 场景下需要注意： ● user.max_user_namespaces=0 只能作为 ESP 变体的辅助缓解，不能替代升级修复内核。 ● 如果攻击者已经拥有真实 CAP_NET_ADMIN，或运行在具备相关能力的特权容器 / 特权服务中，禁用 user namespace 不能阻断这类路径。 RxRPC 场景RxRPC 路径不依赖 user namespace。即使 user.max_user_namespaces=0，如果当前内核启用了 RxRPC，普通用户仍可能通过 add_key("rxrpc", ...)、socket(AF_RXRPC)、splice() 等接口触发相关路径。 因此： ● 如果第 1 节输出 CONFIG_AF_RXRPC=m，应按第 3 节禁用 rxrpc 模块。 ● 如果第 1 节输出 CONFIG_AF_RXRPC=y，rxrpc 已编译进内核，无法通过模块黑名单禁用，应优先升级修复内核或切换不包含该功能的内核。 ● 如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC，无需针对 rxrpc 做禁用处置。 3. 评估影响并临时禁用相关模块只有第 1 节检查结果中出现以下输出时，才适用本节的模块禁用措施： ● CONFIG_INET_ESP=m ● CONFIG_INET6_ESP=m ● CONFIG_AF_RXRPC=m 这些输出表示对应功能以模块形式存在，可以通过 modprobe 黑名单阻止后续加载，并尝试卸载当前已加载模块。 如果输出为 =y，说明对应功能已编译进内核，本节的 modprobe 黑名单和 rmmod 不能完成禁用；应优先升级修复内核、切换不包含该功能的内核，或按第 2 节对 ESP 变体进行辅助降风险。 如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC，无需针对 rxrpc 执行本节禁用命令。 禁用前需要评估影响： ● esp4 / esp6：影响 IPsec ESP，例如 strongSwan、libreswan、站点 VPN、主机到主机 IPsec。 ● rxrpc：影响 RxRPC/kAFS，常见于 AFS 相关场景。 ● user.max_user_namespaces=0：可能影响 rootless Docker、Podman、LXC、沙箱应用、部分 CI 构建环境。 如果业务不依赖这些功能，可以写入 modprobe 黑名单，并卸载当前已加载模块： sudosh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null ||true
4. 验证缓解是否生效再次检查模块是否仍然加载： lsmod |grep -E '^(esp4|esp6|rxrpc)'
如果没有输出，说明当前运行环境中这些模块未加载。 也可以测试是否还能手动加载： sudo modprobe esp4
sudo modprobe esp6
sudo modprobe rxrpc
预期结果是加载失败。
信息中心 2026年5月9日
|
