内核安全 on KnightLi的博客

CVE-2026-43494 / PinTheft：Linux RDS 与 io_uring 组合出的本地提权风险

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 是一个 Linux 内核本地权限提升风险，外界也用 PinTheft 来称呼相关利用链。它的关键不在于远程入口，而在于本地低权限用户能否同时碰到 RDS zerocopy、io_uring fixed buffer、可读 SUID-root 程序和合适的内核版本。

需要先说明一个编号细节：Unclecheng-li/poc-lab 仓库目录名写的是 CVE-2026-43494 PinTheft，README 标题里又写了 QVD-2026-27616 — PinTheft。从公开 CVE 条目和第三方通告看，CVE-2026-43494 指向的是 Linux kernel RDS zerocopy 中 op_nents 未正确重置引发的 double-free / 引用计数异常问题；QVD-2026-27616 更像是奇安信风险通告编号。实际排查时建议同时记录这两个标识，但以发行版安全公告和内核补丁状态为准。

漏洞核心是什么

这个问题出现在 Linux RDS，也就是 Reliable Datagram Sockets 的 zerocopy 发送路径中。公开描述里的关键函数是：

1
2

rds_message_zcopy_from_user()
rds_message_purge()

当 iov_iter_get_pages2() 在 rds_message_zcopy_from_user() 中失败时，已经 pin 住的页面会先被错误路径释放；但相关 op_nents 信息没有被正确清零，后续 rds_message_purge() 仍可能按残留条目再释放一次。结果就是同一批页面引用被多减，形成可被利用的引用计数错误。

单看 RDS bug，它是内核内存管理里的错误路径问题。PinTheft 的危险之处在于利用链把它和 io_uring 固定缓冲区机制连了起来：io_uring 仍保存着旧的 struct page *，而页面本身已经被释放并重新分配给其他用途。PoC 进一步把这个状态引向 SUID-root 程序的 page cache 覆写，最终达到本地提权。

为什么叫 PinTheft

io_uring REGISTER_BUFFERS 会固定用户页。对普通页面来说，FOLL_PIN 并不只是简单增加一个引用，而是通过较大的 bias 增加 page refcount。公开 PoC 中使用了 GUP_PIN_COUNTING_BIAS = 1024 这个概念。

PinTheft 这个名字的意思就是：攻击链通过 RDS zerocopy 的失败路径，一次次“偷走”这些 pin 引用。等引用被耗掉后，io_uring 仍以为自己持有有效页面，但该物理页已经可以被释放并被 page cache 重新占用。

这类漏洞容易被误读成“直接改了磁盘上的 /usr/bin/su”。更准确的说法是：利用链尝试覆写的是内存中的 page cache。文件本体不一定被写回磁盘，但内核执行该 SUID 程序时可能从被污染的页缓存取指令，从而运行攻击载荷。

触发条件并不宽

这不是一个“任意 Linux 服务器都能远程打”的漏洞。公开信息显示，利用链至少依赖这些条件：

内核启用了 CONFIG_RDS 和 CONFIG_RDS_TCP。
系统启用了 CONFIG_IO_URING，且 kernel.io_uring_disabled=0。
rds / rds_tcp 模块已经加载，或低权限用户可以触发自动加载。
本地存在可读的 SUID-root 二进制程序，例如 /usr/bin/su、/usr/bin/passwd、/usr/bin/pkexec。
公开 PoC 还依赖较新的 IORING_REGISTER_CLONE_BUFFERS API，CloudLinux 的分析提到公共 PoC 更偏向 kernel 6.13 及以上形态。

只要其中一环不成立，公开链路就会断掉。比如很多 RHEL 系发行版默认不编译 RDS，Ubuntu 旧内核可能缺少 PoC 需要的 io_uring clone buffer API，部分环境也会限制非特权用户自动加载 RDS 模块。

一分钟自查

先看内核配置：

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

再看 io_uring 是否被禁用：

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

常见含义可以按这个思路理解：

0：允许使用，风险面最大。
1：限制非特权用户使用，具体行为看内核版本和发行版策略。
2：禁用 io_uring。

检查 RDS 模块是否存在、是否可加载：

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

如果 CONFIG_RDS 是 not set，或者系统根本没有 rds_tcp 模块，通常就无法走到这个 bug。反过来，如果 RDS 可用、io_uring 未禁用、系统又是较新的通用内核，就应该提高优先级继续确认发行版修复状态。

哪些机器更值得优先看

优先排查这些环境：

多用户 Linux 主机、教学机、跳板机、共享开发机。
容器宿主机，尤其是允许不可信本地用户或较宽松容器逃逸面的环境。
开启较新 mainline / rolling kernel 的桌面或服务器，例如 Arch 一类滚动发行版。
HPC、Oracle RAC 或其他可能真实使用 RDS 的场景。
允许非特权用户运行大量本地代码的 CI worker、构建机和实验环境。

普通 Web 服务如果只有受控服务账号运行应用，并且 RDS 未启用，实际风险会低很多。但“低很多”不等于不用处理：内核本地提权的典型影响是攻击者先通过 Web、SSH、CI、容器或应用漏洞拿到低权限，再用本地提权扩大控制面。

临时缓解建议

正式修复仍应以发行版内核更新为准。补丁、回溯版本和受影响范围需要看 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、Arch、云厂商或容器基础镜像各自的安全公告，不要只按上游版本号判断。

在等待补丁或无法马上重启内核时，可以按环境选择临时措施：

# 如果业务不依赖 RDS，可阻止相关模块加载
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

如果业务不依赖 io_uring，也可以考虑禁用或限制它：

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

持久化配置需要写入对应的 /etc/sysctl.d/*.conf。不过这一步要谨慎，现代数据库、代理、运行时或高性能 I/O 程序可能使用 io_uring；生产环境修改前最好先确认业务依赖。

修复后怎么验证

升级内核后，不要只看包管理器输出成功。建议确认三件事：

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

如果发行版公告明确写明已修复 CVE-2026-43494，即使 uname -r 看起来不是最新上游版本，也可能是已经回溯补丁的稳定内核。反过来，如果内核来源是自编译、第三方仓库、云市场镜像或容器宿主机模板，就要继续核对补丁 commit 和构建时间。

参考信息

近期四个 Linux 本地提权漏洞影响梳理：Copy Fail、Dirty Frag、Fragnesia 与 ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近 Linux 生态连续出现几起高关注度的本地安全问题。单独看，它们分别落在加密接口、网络/IPsec 路径、页缓存处理、ptrace 访问检查等不同位置；放在一起看，真正值得警惕的是同一个结论：只要攻击者已经拿到低权限本地执行点，Linux 宿主机、容器节点、CI 机器和多用户服务器的风险都会被明显放大。

本文重点不复述每个漏洞的技术细节，而是整理它们对实际环境的影响，并给出站内四篇单独分析文章作为延伸阅读。

四次事件分别影响什么

近期最需要关注的四个风险是：

Copy Fail（CVE-2026-31431）：低权限本地用户可能通过内核加密相关路径影响页缓存，从而扩大权限。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 相关）：风险集中在 xfrm/ESP、RxRPC 等网络和内核数据路径，后渗透阶段危害很高。
Fragnesia（CVE-2026-46300）：与 Dirty Frag 相近，同样围绕 XFRM ESP-in-TCP、共享 fragment 和页缓存写入风险展开。
ssh-keysign-pwn（CVE-2026-46333）：不是直接 root shell 类型漏洞，而是本地信息泄露风险，可能读取 SSH 主机私钥、/etc/shadow 等敏感文件。

这四类问题的入口不同，缓解方式也不完全一样。不能因为处理了 Copy Fail，就默认 Dirty Frag 和 Fragnesia 也安全；也不能因为禁用了某些网络模块，就认为 ssh-keysign-pwn 的信息泄露风险自动消失。

Copy Fail：容器和 CI 节点优先级很高

Copy Fail 的关键影响不是“某个应用崩溃”，而是低权限执行能力可能被转化为 root 权限。它对以下环境尤其敏感：

允许用户上传或运行代码的 CI/CD 节点。
托管不可信工作负载的容器宿主机。
开发测试机、跳板机、共享服务器。
运行旧内核且补丁节奏较慢的云主机。

Copy Fail 的危险点在于攻击门槛偏低，而且容易和容器场景叠加。很多团队把容器当作强隔离边界，但普通容器默认仍共享宿主机内核。如果攻击者能在容器内获得 shell，内核本地提权就可能把容器问题放大为宿主机问题。

详细分析见站内文章：Copy Fail 漏洞 CVE-2026-31431：Linux 内核文件复制路径中的容器逃逸风险。

Dirty Frag：后渗透阶段的放大器

Dirty Frag 更像是攻击者进入系统后的权限放大工具。它不是典型的远程无认证漏洞，前提通常是攻击者已经通过弱口令、WebShell、低权限服务账号、容器任务或其他方式获得本地执行能力。

它的实际影响主要体现在：

已被入侵的低权限账号可能进一步变成 root。
容器环境中的低权限执行点可能威胁宿主机。
使用 IPsec、ESP、RxRPC 或相关内核网络能力的系统需要谨慎评估补丁和临时缓解。
安全团队不能只看边界防护，还要关注入侵后的提权链条。

Dirty Frag 提醒运维团队：本地提权漏洞虽然不是第一入口，却可能决定一次入侵最终能走多远。只要存在低权限落点，攻击者就会寻找内核漏洞把权限推到最高。

详细分析见站内文章：Dirty Frag CVE-2026-43284：Linux 本地提权漏洞风险与缓解指南。

Fragnesia：同类攻击面没有一次性清干净

Fragnesia 的重要性在于，它说明 Dirty Frag 附近的攻击面并不是一个孤立问题。即使某个漏洞被修复，相邻路径、相似数据结构、相同模块组合里仍可能存在新的可利用点。

它对运维的影响主要是：

不能只按漏洞名称做一次性处置，要按攻击面持续检查。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP 等相关路径需要结合业务依赖评估。
如果系统不依赖相关网络能力，可以考虑临时禁用，但必须先在测试环境确认不会影响 VPN、IPsec、隧道或内部网络功能。
页缓存污染类风险可能带来“看似文件没改，实际执行路径受影响”的检测盲点。

Fragnesia 对企业最大的提醒是：补丁管理不能只盯单个 CVE。更稳妥的做法是围绕子系统和攻击面建立清单，确认哪些机器暴露相关能力，哪些业务真正需要这些模块。

详细分析见站内文章：Fragnesia (CVE-2026-46300)：Linux 内核本地提权漏洞影响与缓解。

ssh-keysign-pwn：不直接 root，也足够危险

ssh-keysign-pwn 与前三个漏洞的性质不同。它更偏向本地敏感信息泄露，不是直接拿 root shell 的漏洞。但在真实攻击中，敏感信息泄露常常能变成更严重的后果。

它的影响重点包括：

SSH host private keys 泄露后，可能影响主机身份可信度。
/etc/shadow 等文件被读取后，可能引发离线破解和账号接管。
多用户服务器、跳板机、构建机、共享开发机风险更高。
即使攻击者没有立刻提权，也可能拿到后续横向移动需要的凭据材料。

这类问题容易被低估，因为它没有“直接 root shell”那么刺激。但对企业环境来说，密钥和密码哈希泄露往往意味着更长周期的清理：轮换 SSH 主机密钥、排查信任关系、检查账号密码、审计登录日志，都可能成为必要动作。

详细分析见站内文章：ssh-keysign-pwn（CVE-2026-46333）解读：Linux 本地信息泄露、SSH 主机密钥与 /etc/shadow 风险。

共同影响：容器隔离不能再被当作强边界

这四次事件合在一起，最直接的影响是重新提醒大家：普通容器隔离不是虚拟机隔离。

Docker、containerd 和 Kubernetes 依赖 namespace、cgroup、capabilities、seccomp、AppArmor 或 SELinux 等机制减少攻击面，但它们通常仍共享宿主机内核。只要漏洞发生在共享内核里，容器内的低权限执行点就可能成为攻击入口。

高风险环境应重点检查：

是否允许不可信代码运行在共享宿主机上。
容器是否默认 root 用户运行。
是否授予了不必要的 capabilities。
seccomp 配置是否过宽。
多租户工作负载是否应该迁移到 gVisor、Kata Containers、Firecracker microVM、独立虚拟机或专用节点。

对 CI/CD 平台尤其要谨慎。构建任务天然会运行外部代码、依赖安装脚本、测试脚本和临时二进制。如果这些任务与长期服务共享宿主机，一次本地提权就可能影响更大的基础设施。

共同影响：补丁必须落到“正在运行的内核”

Linux 内核补丁有一个很常见的误区：包管理器显示已经更新，不代表机器正在运行新内核。

运维上至少要确认三件事：

`1`	`uname -a`

确认当前运行内核版本。

`1`	`dpkg -l \| grep linux-image`

或在 RHEL 系发行版上：

`1`	`rpm -qa \| grep kernel`

确认已安装内核包。

最后，还要确认机器已经重启到修复后的内核。对不能重启的核心业务，要评估 livepatch、热补丁或短期隔离方案，但不要把临时缓解当作最终修复。

共同影响：攻击面最小化要具体到模块和系统调用

这几次漏洞涉及的路径提醒我们，Linux 加固不能只停留在“更新系统”和“开防火墙”。

更具体的检查方向包括：

AF_ALG / algif_aead 是否被业务使用。
XFRM、ESP、ESP-in-TCP、IPsec 是否被 VPN、隧道或安全网关依赖。
RxRPC 是否需要启用。
非特权用户命名空间是否必须开放。
容器是否能创建过宽的 socket 类型。
ptrace 访问策略是否过松。

如果业务确实不需要某些能力，可以评估禁用模块、调整 sysctl、收紧 seccomp、减少 capabilities。生产环境不要盲目复制命令，应先盘点依赖，再灰度执行。

建议的处置顺序

第一，优先修复可本地执行代码的高暴露机器：

容器宿主机。
CI/CD runner。
跳板机。
多用户服务器。
对外服务所在主机。
运行不可信插件、脚本、扩展的系统。

第二，确认发行版公告和实际运行内核。不要只看上游版本号，Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler 等发行版可能会 backport 安全补丁。

第三，收紧容器运行策略。尽量做到非 root 用户、最小 capabilities、no-new-privileges、只读文件系统、明确 seccomp 和 AppArmor/SELinux 策略。

第四，检查密钥和凭据风险。尤其是涉及 ssh-keysign-pwn 的环境，应评估 SSH host key、/etc/shadow、跳板机凭据和 CI secrets 是否需要轮换。

第五，补上监控。重点关注异常 root shell、可疑本地提权 PoC、关键文件修改、异常 ptrace 行为、容器进程访问宿主机路径、CI 节点上的异常网络连接。

结论

这四次事件的重点不是“Linux 不安全了”，而是“默认信任不够用了”。

Linux 仍然是透明、可修复、可裁剪、可加固的主流系统。但在容器、CI、多租户和 AI 自动化代码执行越来越普遍的环境里，低权限执行点已经不能被看作小问题。只要内核里存在可利用的本地提权或敏感信息泄露漏洞，局部入侵就可能变成宿主机控制、凭据泄露或横向移动。

更现实的做法是把这四次事件当成一次提醒：补丁要快，重启要确认，模块要按需启用，容器要收紧，密钥要能轮换，多租户要重新评估隔离等级。

站内延伸阅读：

ssh-keysign-pwn（CVE-2026-46333）解读：Linux 本地信息泄露、SSH 主机密钥与 /etc/shadow 风险

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn 是围绕 Linux kernel __ptrace_may_access() 逻辑问题公开的一组利用路径，CVE 编号为 CVE-2026-46333。它不是远程无认证漏洞，也不是直接拿 root shell 的漏洞，但风险仍然很高：本地低权限用户可能读取本不该访问的 root 敏感文件，例如 SSH 主机私钥或 /etc/shadow。

对运维来说，重点不是复现 PoC，而是尽快判断哪些机器受影响、升级内核、重启生效，并在必要时轮换 SSH host keys 和重置密码。

先说结论

这次漏洞的处置优先级很高，原因有四点：

触发条件是本地低权限用户，不需要 root。
已有公开 PoC，利用门槛明显降低。
影响目标不是普通文件，而可能是 SSH 主机私钥和 /etc/shadow。
修复需要内核补丁并重启，不能只升级包后不重启。

如果你的服务器有多用户、本地 shell、共享主机、CI runner、容器宿主机、学生机房、跳板机或任何“不完全可信本地用户”，应该优先处理。

漏洞是什么

Qualys 在 2026 年 5 月 15 日通过 oss-security 公开说明：他们此前向 security@kernel.org 报告了 Linux kernel __ptrace_may_access() 的逻辑问题，上游修复已经由 Linus 合入。随后社区出现了公开利用代码，因此 Qualys 将信息发到 oss-security。

Linux kernel CVE 团队随后为这个问题分配了 CVE-2026-46333。NVD 页面显示该 CVE 来源为 kernel.org，问题描述对应内核提交 ptrace: slightly saner 'get_dumpable()' logic。

简单说，这个漏洞出现在进程退出路径上。某些特权进程正在退出时，内核里与 ptrace 访问检查相关的逻辑可能因为目标任务已经没有 mm 而绕过本应依赖的 dumpable 检查。攻击者可以在很窄的竞态窗口中，拿到正在退出的特权进程仍然打开着的文件描述符。

这也是为什么它被叫作 ssh-keysign-pwn：公开利用路径之一会围绕 ssh-keysign 读取 SSH host private keys。

为什么能读到 SSH 主机私钥和 /etc/shadow

这个问题本质上是本地信息泄露。它利用的是特权程序在退出过程中“内存描述符已经脱离，但文件描述符还没关闭”的时间窗口。

AlmaLinux 的公告对风险讲得比较清楚：如果特权程序在降权前打开了敏感文件，而攻击者在退出窗口中成功拿到对应文件描述符，就可能读取这些敏感文件。

公开讨论中常见的两个目标是：

ssh-keysign：可能涉及 /etc/ssh/ssh_host_*_key 这类 SSH 主机私钥。
chage：可能涉及 /etc/shadow。

SSH 主机私钥泄露后，攻击者可能伪装成该主机，影响 SSH 主机身份信任。/etc/shadow 泄露后，攻击者可以离线破解密码哈希，进一步扩大影响。

这也是为什么它虽然不是“直接 root shell”，但仍然应按高优先级处理。

影响范围怎么判断

从上游角度看，这是 Linux kernel 的漏洞。NVD 记录显示该问题在 2026 年 5 月 15 日进入 NVD 数据集，NVD 当时还没有给出 CVSS 评分。

发行版层面的状态要以各自公告为准：

AlmaLinux 8、9、10 都发布了处理说明，并在 2026 年 5 月 16 日更新称 patched kernels 已进入生产仓库。
Debian security tracker 已列出 bullseye、bookworm、trixie、sid 等分支的 vulnerable/fixed 状态和固定版本。
其他发行版需要分别查看 Ubuntu、Red Hat、SUSE、Arch、Alpine 等官方安全页面或更新源。

不要只按内核大版本判断是否安全。发行版会 backport 修复，同一个上游版本号在不同发行版中可能代表不同补丁状态。

应该优先处理哪些机器

建议按风险排序处理：

多用户服务器和共享主机。
有普通 shell 账号的跳板机、教学机、开发机。
CI runner、构建机、托管平台宿主机。
容器宿主机和虚拟化宿主机，尤其是不完全可信 workload 共存的环境。
公开服务机器，虽然漏洞需要本地访问，但一旦 Web/RCE/弱口令带来低权限落点，风险会叠加。

纯单用户桌面环境风险相对低一些，但仍建议随系统更新修复。原因很简单：本地低权限代码执行在桌面上并不少见，浏览器、开发工具、脚本和第三方软件都可能成为落点。

修复建议

首选方案是安装发行版提供的修复内核并重启。

不同发行版命令不同，原则相同：

更新软件源元数据。
安装包含 CVE-2026-46333 修复的 kernel 包。
重启进入新内核。
用 uname -r 和发行版安全公告核对当前运行内核是否已修复。

AlmaLinux 公告中提到，生产仓库已推出修复内核，用户可以执行常规 dnf upgrade 并重启。Debian tracker 也列出了多个分支的 fixed versions。

需要注意：只安装新 kernel 包但不重启，旧内核仍在运行，漏洞仍然存在。

临时缓解：收紧 ptrace_scope

如果暂时不能重启，可以先收紧 Yama 的 ptrace_scope。

Qualys 在 oss-security 后续回复中确认，将 /proc/sys/kernel/yama/ptrace_scope 设置为 2（admin-only attach）或 3（no attach）可以阻止他们已知的公开利用路径。但他们也说明，理论上可能存在其他利用方式，所以这只是缓解，不是修复。

临时设置可以用：

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

持久化可以写入 sysctl 配置：

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 会禁用 ptrace attach，可能影响 gdb、strace -p 等调试场景。如果生产环境需要调试，可以评估使用 2。无论选哪一个，都应尽快安排内核升级和重启。

是否需要轮换 SSH 主机密钥

如果机器在漏洞公开前后存在以下情况，建议保守处理：

有不可信本地用户。
有共享主机或容器/CI 多租户环境。
有 Web 漏洞、弱口令、供应链脚本等可能给攻击者本地落点。
日志中出现可疑本地进程、异常调试行为或公开 PoC 文件。
机器在修复前暴露了较长时间。

保守处置包括：

修复并重启后轮换 SSH host keys。
更新已知主机指纹管理系统。
通知依赖该主机指纹的自动化系统。
检查 SSH 连接告警，避免误把合法指纹变化当成中间人攻击或反过来忽略真实风险。

如果怀疑 /etc/shadow 已泄露，还应评估密码重置、禁止弱密码、检查是否存在可离线破解的旧哈希。

需要监控什么

这类漏洞利用窗口很短，传统日志未必能完整记录。但仍可以关注：

普通用户目录下是否出现 ssh-keysign-pwn、chage_pwn 或类似 PoC 文件。
可疑编译行为，例如短时间内编译陌生 C 程序。
异常访问 /etc/ssh/ssh_host_*_key、/etc/shadow 的迹象。
异常 pidfd_getfd、ptrace、调试器相关行为。
SSH 主机指纹被外部系统报告异常。

这些信号不能证明一定被利用，也不能证明没有被利用。真正的优先事项仍然是补丁、重启、凭据轮换和风险隔离。

常见误区

第一个误区：它不是 OpenSSH 远程漏洞。名字里有 ssh-keysign，但根因在 Linux kernel 的 ptrace 访问检查逻辑，不是 sshd 远程认证流程。

第二个误区：没有本地用户就完全没风险。漏洞确实需要本地执行条件，但很多真实攻击链会先通过 Web 服务、CI、脚本、弱口令或容器逃逸前置步骤获得低权限本地落点。

第三个误区：设置 ptrace_scope 就够了。它是临时缓解，不是根本修复。内核更新和重启仍然需要做。

第四个误区：只要没被拿 root 就没事。SSH 主机私钥和 /etc/shadow 的泄露本身就足以导致后续横向移动、主机伪装和离线破解风险。

处置清单

建议按这个顺序执行：

盘点受影响 Linux 主机，特别是多用户和共享环境。
查看发行版官方安全公告，确认 fixed kernel 版本。
安装修复内核并重启。
暂时不能重启的机器，先设置 kernel.yama.ptrace_scope=2 或 3。
修复后核对正在运行的内核版本。
对高风险机器轮换 SSH host keys。
如果怀疑 /etc/shadow 泄露，评估密码重置和账号审计。
检查是否存在公开 PoC、异常编译和可疑本地调试行为。

总结

ssh-keysign-pwn（CVE-2026-46333）是一个本地信息泄露漏洞，根因在 Linux kernel __ptrace_may_access() 相关逻辑。它不需要远程直接打进来，也不直接给 root shell，但可以让低权限本地用户读取高价值敏感文件，这使它在多用户、共享主机、CI 和容器宿主环境中非常值得警惕。

最可靠的修复是升级到发行版提供的修复内核并重启。ptrace_scope=2/3 可以作为临时缓解，但不能替代补丁。已经暴露在风险窗口中的关键主机，还应考虑 SSH 主机密钥轮换和密码风险评估。

参考链接：

Dirty Frag CVE-2026-43284：Linux 本地提权漏洞风险与缓解指南

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag 是 2026 年 5 月公开并已出现利用迹象的一组 Linux 内核本地提权漏洞。Microsoft 将其描述为攻击者在已经获得低权限执行能力后，用来把权限提升到 root 的后渗透风险；Ubuntu 也将 CVE-2026-43284 标为 High。

这类漏洞最危险的地方不在“远程直接打进来”，而在“进来以后迅速扩大控制权”。一旦攻击者通过弱 SSH 账号、WebShell、容器逃逸、低权限服务账号或钓鱼后的远程访问拿到本地执行机会，就可能利用 Dirty Frag 获取 root，进而关闭安全工具、读取敏感凭据、篡改日志、横向移动或建立持久化。

Dirty Frag 涉及哪些 CVE

目前公开信息里，Dirty Frag 主要关联两个编号：

CVE-2026-43284：涉及 Linux 内核 xfrm/ESP 路径，Microsoft 提到的 esp4、esp6 组件属于这一类风险。
CVE-2026-43500：Microsoft 称其与 rxrpc 相关，但截至 2026 年 5 月 8 日，该 CVE 在 NVD 尚未正式发布，补丁状态也仍在变化。

因此，实际排查时不要只盯一个 CVE。更稳妥的思路是同时关注 esp4、esp6、rxrpc 以及相关 xfrm/IPsec 功能是否启用、是否需要、是否已有发行版内核补丁。

技术原因简单理解

根据 Microsoft 和 Ubuntu 的说明，CVE-2026-43284 与 Linux 内核网络和内存碎片处理有关，尤其是 ESP/IPsec 路径中对共享页面片段的处理。

更具体地说，某些场景下，数据页可能通过 splice 等机制被挂到网络缓冲区里。如果内核后续路径把这些片段当成可以原地修改的私有数据处理，就可能在不该写的位置发生原地解密或修改。攻击者可以借此操纵 page cache 行为，最终达到本地提权。

这和此前披露的 CopyFail（CVE-2026-31431）有相似背景：都围绕 Linux page cache、内核数据路径和本地提权展开。Dirty Frag 的危险点在于，它引入了更多攻击路径，可能比传统依赖竞态窗口的 LPE 更稳定。

哪些环境需要优先关注

Dirty Frag 是本地提权漏洞，所以前提是攻击者已经能在目标机器上执行代码。需要优先关注的环境包括：

暴露 SSH 的 Linux 服务器。
运行 Web 应用、可能被写入 WebShell 的服务器。
多用户登录、跳板机、开发机、CI/CD runner。
容器宿主机、Kubernetes 节点、OpenShift 节点。
使用 IPsec、VPN、xfrm、RxRPC 相关功能的系统。
运行 Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE 等主流发行版的服务器。

如果你的服务器完全没有本地多用户、没有容器、没有暴露可被利用的应用入口，风险会低一些；但只要存在“攻击者可能拿到低权限 shell”的路径，就应该把它作为高优先级内核漏洞处理。

先做补丁优先

最稳妥的修复方式永远是安装发行版提供的内核安全更新，并重启进入新内核。

Ubuntu 的 CVE 页面显示，CVE-2026-43284 发布于 2026 年 5 月 8 日，优先级为 High。Microsoft 也指出 Linux Kernel Organization 已经发布 CVE-2026-43284 相关修复，并建议尽快应用补丁。

实际操作建议：

1
2

uname -a
cat /etc/os-release

然后按发行版更新内核：

`1`	`sudo apt update && sudo apt full-upgrade`

或：

`1`	`sudo dnf update`

更新后务必确认已重启到新内核：

`1`	`uname -r`

只安装内核包但不重启，旧内核仍在运行，漏洞依然可能存在。

临时缓解：禁用相关模块

如果补丁尚未可用，或生产环境不能立即重启，可以先评估是否能临时禁用相关模块。Ubuntu 给出的缓解思路是阻止 esp4、esp6、rxrpc 加载，并卸载已经加载的模块。

创建 modprobe 禁用规则：

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

更新 initramfs，避免早期启动阶段加载：

`1`	`sudo update-initramfs -u -k all`

卸载已加载模块：

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

确认模块是否仍在：

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

如果模块正在被业务使用，可能无法卸载，重启后禁用规则才会生效。

禁用前一定要评估业务影响

不要把上面的缓解命令当成无脑复制粘贴。esp4、esp6 和 xfrm/IPsec 相关功能可能被 VPN、隧道、加密网络、Kubernetes/容器网络或特定企业网络配置使用。rxrpc 也可能影响依赖该协议的场景。

在生产环境执行前，至少确认：

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

如果你依赖 IPsec VPN 或相关内核网络功能，禁用模块可能直接导致连接中断。此时更推荐尽快安排内核补丁和维护窗口，而不是长期依赖禁用模块。

入侵后检查不能省

Microsoft 特别提醒，缓解措施不一定能撤销已经发生的成功利用。攻击者如果已经拿到 root，可能留下持久化、篡改文件、修改日志或访问 session 数据。

建议至少检查：

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

还应重点关注：

异常 su、sudo、SUID/SGID 进程启动。
近期新增的 ELF 可执行文件。
Web 目录下的可疑 PHP、JSP、ASP 文件。
SSH authorized_keys 是否被改动。
systemd service、cron、rc.local 是否新增持久化。
容器宿主机是否有异常特权容器或挂载。

如果怀疑已经被利用，优先隔离主机、保留证据、轮换凭据，再做清理。不要只靠卸载模块或清缓存就认为安全。

关于 drop_caches

Microsoft 文中提到，在某些入侵后完整性验证场景，可以评估是否清理缓存：

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

但这不是漏洞修复命令，也不是入侵清理命令。清 cache 可能带来额外磁盘 I/O 和生产性能影响，只适合在理解影响后作为辅助操作。真正的修复仍然是打补丁、重启、检查完整性和排查持久化。

总结

Dirty Frag 不是一个“远程一键打穿”的漏洞，但它会显著放大已经入侵后的风险。只要攻击者能获得本地低权限执行机会，就可能借助 CVE-2026-43284 以及相关 rxrpc 攻击面把权限提升到 root。

对管理员来说，重点不是研究 PoC，而是尽快完成三件事：确认内核是否受影响，安装发行版安全更新并重启；在补丁窗口前评估禁用相关模块；对已经暴露或疑似被入侵的系统做完整性和持久化检查。