漏洞分析 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 和构建时间。

参考信息

CVE-2026-42945 怎么排查？Nginx Rift 漏洞触发条件、版本检查与升级建议

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一个安全漏洞，外界也把它称为 Nginx Rift。它出现在 ngx_http_rewrite_module，漏洞类型是 heap-based buffer overflow。

这类新闻很容易被写成“潜伏 18 年”“不用密码远程控制”“三成服务器中招”。这些说法有传播性，但看补丁和 NVD 描述时，最好把风险拆开看：它确实严重，也确实不需要登录账号；但并不是所有 Nginx 实例都会自动被接管，触发需要特定 rewrite 配置和请求条件。

先看官方描述

NVD 对 CVE-2026-42945 的描述可以概括为：

影响 NGINX Plus 和 NGINX Open Source。
漏洞位于 ngx_http_rewrite_module。
当 rewrite 指令后面跟着 rewrite、if 或 set 指令，并且使用未命名的 PCRE 捕获组，例如 $1、$2，同时替换字符串里包含问号 ? 时，可能触发问题。
未认证攻击者可以发送构造请求触发漏洞。
结果可能是 NGINX worker 进程发生 heap buffer overflow 并重启。
如果系统关闭了 ASLR，存在代码执行可能。

F5 作为 CNA 给出的评分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，这不是普通的“配置写错导致 404”问题，而是 Nginx 官方安全修复范围内的内存安全漏洞。

哪些说法需要降温

第一，“不用密码”基本可以理解为未认证攻击。也就是说，攻击者不需要登录 Nginx 后台，不需要拿到 SSH，也不需要应用系统账号。但这不等于任何公网 Nginx 都能被随手接管。

第二，“直接远程控制”要看条件。官方描述里更稳妥的说法是：漏洞可导致 worker 进程重启；在 ASLR 关闭的系统上，代码执行是可能结果。对启用了 ASLR、发行版编译加固完整、运行权限受限的环境，风险路径会更复杂。

第三，“30% 服务器中招”不能简单等同于“所有 Nginx 市占率都是漏洞暴露面”。真正暴露要同时看版本、是否启用受影响模块、是否存在特定 rewrite 配置、发行版是否已经回补补丁，以及 Nginx 运行环境的加固状态。

更准确的判断方式是：只要你在生产环境运行 Nginx，就应该尽快检查；但不要只按标题里的比例判断自己是否中招。

受影响范围怎么判断

从 nginx.org 发布信息看，2026 年 5 月 13 日发布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多项安全修复，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 源码或官方包，可以优先关注：

NGINX Open Source stable：升级到 1.30.1 或之后版本。
NGINX Open Source mainline：升级到 1.31.0 或之后版本。
NGINX Plus：查看 F5 对应分支的修复版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器镜像、Plesk、宝塔、Ingress Controller 或云厂商托管组件，不要只看 nginx -v 里的上游版本号。很多发行版会把安全补丁 backport 到旧版本包里，版本号看起来旧，但补丁可能已经合入。

一分钟判断是否需要紧急处理

可以先按下面几个问题快速分级：

这台 Nginx 是否直接暴露在公网，或者位于 API Gateway、反向代理、负载均衡、Ingress 入口层？
是否使用官方 Nginx 包、源码编译包、第三方面板、容器镜像，且还没有确认 CVE-2026-42945 修复状态？
配置里是否存在复杂 rewrite 规则，尤其是连续 rewrite、if、set，以及 $1、$2 这类未命名捕获组？
是否存在把请求路径、查询参数或用户可控输入带入 rewrite 目标的场景？
系统加固是否较弱，例如 ASLR 被关闭、worker 权限过高、容器权限过宽？

如果前两项命中，并且 rewrite 配置还没有排查，建议按高优先级处理。公网入口、共享环境、Kubernetes Ingress、边缘代理和承载登录/API 流量的 Nginx，应该优先升级或替换到确认修复的包。

Debian / Ubuntu / RHEL / Alpine 如何确认修复

发行版用户不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 这类系统经常把安全补丁回补到稳定分支，表面版本号可能仍然低于 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以优先看安全公告、包 changelog 和可升级列表：

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和包变更记录：

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以检查当前包版本和安全分支更新：

1
2

apk info -v nginx
apk version -v nginx

如果包管理器、发行版安全公告或厂商 advisory 明确写明已修复 CVE-2026-42945，即使上游版本号看起来不新，也可以按“已回补修复”处理。反过来，如果只是版本号较高但来源不明，仍然要确认构建日期和补丁来源。

容器镜像与 Ingress Controller 怎么查

容器环境要检查镜像里的 Nginx，而不是只看宿主机。先确认镜像实际内置版本：

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

还要看基础镜像是否更新过。如果镜像基于 Debian、Ubuntu、Alpine 或发行版包构建，判断方式应回到对应发行版的安全公告和包 changelog。只重启旧镜像没有意义，镜像本身需要重新构建或替换。

Kubernetes Ingress 需要同时确认三件事：

Ingress Controller 项目是否发布了针对 CVE-2026-42945 的 advisory 或修复版本。
当前集群运行的 controller 镜像 digest 是否已经更新，而不是只改了 tag。
controller 内置 Nginx 版本、构建参数和模板配置是否仍然包含高风险 rewrite 规则。

可以先看运行中的镜像：

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用云厂商托管 Ingress 或网关，还要查对应云服务公告。托管组件通常不是用户自己 apt upgrade 能解决的，需要等待厂商修复或切换到已修复版本。

rewrite 配置重点排查哪些写法

这个漏洞和 rewrite 配置有关，排查时可以先搜索 Nginx 配置：

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重点关注类似模式：

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

这里的 $1、$2 这类未命名捕获组，以及替换目标中的 ?，是官方描述里的关键条件之一。排查时尤其关注下面几类写法：

一个 rewrite 后面紧跟另一个 rewrite、if 或 set。
正则里使用 (.*)、(.+) 这类宽泛捕获，并在目标里用 $1、$2。
rewrite 目标里带 ?，用于拼接或丢弃查询参数。
rewrite 输入来自公网路径、Host、URI、参数或上游可控值。
面板、网关、Ingress 注解或模板自动生成的 rewrite 规则。

如果短时间内无法升级，可以先做临时缓解：

减少复杂 rewrite 规则。
把未命名捕获组改成更清晰的命名捕获。
避免在替换字符串里拼接不必要的 ?。
对高风险入口加 WAF 或反向代理规则。
确认系统启用了 ASLR。
降低 Nginx worker 运行权限，确认 systemd sandbox、SELinux/AppArmor 等加固状态。

这些只是缓解，不是替代补丁。

修复优先级

建议按暴露面排序：

公网入口 Nginx。
反向代理、API Gateway、边缘网关。
多租户环境里的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、云市场镜像等自带 Nginx 的组件。
内网但承载关键业务的 Nginx。

升级后如何验证：nginx -t、reload、worker 状态

更新后不要只看包管理器提示成功，还要确认配置、进程和实际二进制都已经切换。先验证配置：

`1`	`nginx -t`

确认没有错误后再平滑加载：

`1`	`systemctl reload nginx`

如果包升级涉及二进制替换，建议确认旧 worker 已退出：

`1`	`ps aux \| grep nginx`

也可以查看主进程启动时间和二进制路径，确认运行中的服务不是旧进程继续驻留。必要时安排维护窗口重启服务，避免旧 worker 或旧容器继续处理请求。

容器和 Ingress 环境还要确认新镜像已经真正滚动完成：

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

验证重点不是“命令执行过”，而是“线上流量已经由包含修复的 Nginx 进程承载”。

不要忽略同批次 Nginx 修复

nginx.org 在同一天发布的 1.30.1 和 1.31.0 不只修复了 CVE-2026-42945。发布信息还提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等问题。

这意味着生产环境不应该只针对单个 CVE 做临时规则，而是应该把 Nginx 这一轮安全更新当成一次整体升级来处理。

小结

CVE-2026-42945 的关键点不是“所有 Nginx 都会被秒控”，而是：一个长期存在于 rewrite 模块里的内存安全漏洞，在特定配置下可被未认证请求触发，最直接后果是 worker 崩溃重启；在 ASLR 关闭等较弱环境下，代码执行风险更高。

对运维来说，处理顺序很简单：

确认 Nginx 来源和版本。
查看发行版、F5、nginx.org 或云厂商公告。
尽快升级到包含修复的版本或发行版安全包。
排查复杂 rewrite 配置，尤其是 $1、$2 和 ? 组合。
确认 ASLR、权限隔离和服务重载状态。

标题可以吓人，修复要冷静。先确认暴露面，再升级，再回头清理高风险 rewrite 规则。

参考链接

Copy Fail 漏洞 CVE-2026-31431：Linux 内核文件复制路径中的容器逃逸风险

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一个影响 Linux 内核文件复制路径的漏洞，编号为 CVE-2026-31431。 Bugcrowd 的分析把它称为一个值得关注的内核级问题：在特定条件下，非特权用户可以利用文件复制相关逻辑触发越权写入，进而造成权限提升或容器逃逸。

从风险角度看，它不是普通应用层漏洞。问题发生在内核处理文件复制和页面缓存的路径上，因此影响面会延伸到容器、共享主机、CI/CD Runner、PaaS 平台和多租户 Linux 环境。如果攻击者已经能在系统里运行低权限代码，漏洞就可能成为进一步突破隔离边界的跳板。

漏洞大致发生在哪里

Copy Fail 关联的是 Linux 内核中的文件复制能力。现代 Linux 提供了多种高效复制路径，例如 copy_file_range、splice 类路径以及不同文件系统之间的数据复制优化。这些机制的目标是减少用户态和内核态之间的数据搬运，提高大文件复制性能。

问题在于，高性能复制路径通常会复用页缓存、文件偏移、权限检查和文件系统回调。如果其中某个边界条件处理不严，内核可能在错误的权限上下文里执行写入，或者把本不应该被修改的数据页暴露给攻击者控制。

Copy Fail 的核心风险可以概括为：

攻击者不需要 root 权限；
攻击入口来自常见文件复制能力；
影响点在内核态；
在容器环境里，漏洞可能绕过命名空间和挂载隔离；
成功利用后可能写入宿主机上不应被容器修改的内容。

这也是它被重点讨论的原因。容器安全依赖 Linux 内核提供隔离能力，一旦内核路径本身出现越权写入，容器边界就会变得脆弱。

为什么容器场景更敏感

容器并不是虚拟机。容器内进程和宿主机共享同一个 Linux 内核，只是通过 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等机制做隔离。

如果漏洞发生在用户态服务里，通常只影响某个容器或某个进程。但如果漏洞发生在内核里，尤其是可以被非特权用户触发的内核漏洞，攻击者可能从容器内部影响宿主机。

Copy Fail 的危险点就在这里。很多平台允许用户提交构建任务、运行脚本、启动容器或执行插件。攻击者只要能在容器里运行代码，就可能尝试利用内核文件复制路径突破隔离。

高风险环境包括：

Kubernetes 集群中的不可信工作负载；
CI/CD 平台的共享 Runner；
允许用户上传代码执行的沙箱平台；
多租户 Linux 主机；
容器化 PaaS；
运行第三方插件或扩展的系统。

如果这些环境里的内核版本处于受影响范围，而且缺少额外限制，风险就会明显升高。

受影响范围要看内核补丁状态

这类漏洞的判断不能只看发行版名称。同一个 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影响取决于当前实际运行的内核包，以及发行版是否已经回补补丁。

排查时应优先确认三件事：

当前运行内核版本；
发行版安全公告是否提到 CVE-2026-31431；
云厂商或托管平台是否已经完成宿主机内核修复。

可以先在系统上确认内核版本：

`1`	`uname -a`

然后查看发行版安全公告、内核 changelog 或云平台公告。不要只根据主版本号判断是否安全，因为很多企业发行版会把安全补丁回补到旧版本内核里。

临时缓解思路

最可靠的修复方式仍然是更新内核。但在补丁无法立刻部署的环境里，可以先降低暴露面。

常见缓解方向包括：

禁止不可信用户运行特权容器；
避免给容器挂载敏感宿主机路径；
收紧容器 capability，尤其不要随意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危险系统调用和文件访问；
将不可信工作负载迁移到隔离更强的虚拟机；
对 CI/CD Runner 做按任务销毁，避免长期复用同一宿主机；
监控异常文件写入、权限变更和容器逃逸迹象。

这些措施不能替代补丁。它们的作用是降低攻击成功率和影响面，特别是在补丁发布到生产环境之前争取缓冲时间。

修复优先级

建议按环境风险排序处理。

优先修复：

对外提供容器执行能力的平台；
运行不可信代码的 CI/CD 节点；
多租户 Kubernetes 节点；
有用户自定义插件或脚本执行能力的系统；
共享开发机、教学机、实验平台。

相对低优先级：

单用户桌面；
只运行可信服务的内网主机；
已经使用虚拟机隔离不可信代码的环境。

即便风险较低，也建议随发行版更新内核。内核漏洞常常会被组合进更复杂的攻击链里，拖延补丁没有太多收益。

给运维团队的检查清单

可以按下面顺序处理：

盘点所有 Linux 主机和容器节点；
标记会运行不可信代码的机器；
检查当前内核版本和发行版安全公告；
优先更新高风险节点；
对无法立即更新的节点启用临时隔离策略；
检查容器运行时配置，移除不必要的特权和宿主机挂载；
更新后重启节点，确认新内核已经实际生效；
保留变更记录，方便后续审计。

内核包安装完成并不代表系统已经运行在新内核上。更新后必须重启，并再次确认：

`1`	`uname -a`

小结

Copy Fail / CVE-2026-31431 的重点不是某个应用崩溃，而是 Linux 内核文件复制路径中的权限边界问题。它让非特权代码有机会触碰更高权限的数据写入路径，因此在容器和多租户环境里尤其值得重视。

处理这类漏洞时，最重要的是两件事：

尽快跟进发行版或云厂商提供的内核补丁；
在补丁部署前限制不可信代码、特权容器和敏感宿主机挂载。

对个人桌面来说，它可能不是马上需要恐慌的问题。但对运行容器平台、CI/CD、沙箱和共享主机的团队来说，应该把它当作高优先级内核安全更新处理。

参考来源：