Stealthium团队发现NVIDIA驱动提权漏洞NvRoot，可让普通用户获取主机root权限

NvRoot（CVE-2026-47591）是 Stealthium 团队发现的一个 NVIDIA 驱动本地权限提升漏洞。我们构建了一个可用的 exploit 来演示该漏洞并确认能获取 root，随后将其报告给了 NVIDIA。我们还针对该漏洞的利用行为构建了检测方案，并在补丁发布之前就已上线运行。今天我们要公开的内容足以让人理解并防御该漏洞：不提供 proof-of-concept，部分细节予以保留。按照负责任的披露流程，我们在 AI 运行时栈中还有 25 个以上的 High 或 Critical 漏洞。

租用一块 GPU 的一个切片。如果它运行的是受影响的版本，借助这个漏洞，你就能拿到宿主机的 root 权限。隔壁租户的环境，从模型权重到实时推理，全部唾手可得。欢迎来到 NvRoot。

事实是，GPU 驱动经常做一些在其他地方会让安全工程师紧张不已的事情。它们取走属于非特权进程的内存，让第二个处理器——GPU——直接读写这些内存。这种安全模型只有在驱动对"哪些内存"以及"谁可以对它做什么"都一丝不苟时才能成立。

在 NvRoot（CVE-2026-47591）中，NVIDIA 驱动的一个调用信任了错误的权限字段，于是一个非特权用户变成了 root。对于因 neocloud 而流行起来的多租户 GPU 环境来说，这就是灭顶之灾。让我们深入看看。

一个单独的 pin 请求，两个权限字段互相矛盾，就把 GPU 的写权限交给了一个调用者只能读取的文件。把它对准一个全局可读的 setuid 二进制文件，比如 /usr/bin/su，用 payload 覆盖它在内存中的副本，然后运行它：内核认可真实的 setuid 位，却加载了你写入的字节。一次 ioctl > 一次 GPU 写入 > root。

值得注意的是，这一切都不像是一次 exploit。没有内核内存被破坏，没有符号被解析，没有偏移被猜测，没有竞争条件要赢。攻击者发出的 pin 调用和每个 CUDA 程序发出的一样，GPU 写入也和每个 CUDA 程序做的一样。在受影响的驱动上，返回的映射是可写的。这个漏洞是确定性的、与内核版本无关，从非特权容器内部触发和在裸机上触发效果完全相同。

NvRoot 归结起来就是：在受影响的驱动上，GPU 可以写入只读文件。下面说明这如何转化为 root。

我们认为，自然而然的、也是已知的（读作：恶意的）做法是向一个 setuid 程序投毒。用一小段 payload 覆盖 /usr/bin/su 之类程序在内存中的副本，然后运行它。内核从磁盘读取真实且未被改动的 setuid 位并授予 root，然后执行我们在内存中改写过的副本。注意，由于磁盘上的文件从未改变，文件完整性检查不会发现任何异常。我们端到端地构建了这套利用，并亲眼看到它返回了一个 root shell。

一个非特权用户（uid 1001）把 /usr/bin/su 变成了一块 GPU 可写的表面，覆盖其缓存副本，然后 exec 进入 root shell。

已在驱动 610.43.02 上确认可获取 root，并在 610.57.04 上确认已修复——在该版本中，写入在 pin 阶段就被拒绝。

至于一个本地 root 漏洞如何对租用多租户 GPU 的双方都构成问题……

NvRoot 所污染的内存与宿主机共享。

从一个拥有 GPU 访问权限的非特权容器（作为 neocloud 客户你就能买到这样的容器）出发，这就是宿主机级别的沦陷：被投毒的二进制正是宿主机和其他所有租户所执行的那一个。攻击跨越容器边界的方式，与它在裸机上跨越用户边界的方式完全相同。

NVIDIA 将此漏洞评为 CVSS 7.8 High。然而，从上述情况可以清楚地看出，在多租户环境中这实质上意味着"租用 = root"。因此，在这类环境中，我们建议将其视为 Critical 处理。

进程请求驱动 pin 住内存，以便 GPU 能够访问。该请求携带两个独立的权限：一个规定 CPU 侧可以对该内存做什么，另一个规定 GPU 侧可以做什么。它们本应相互独立，并且两者都应被强制执行。

受影响的驱动仅根据 CPU 字段推导实际的页权限，从不检查另一个字段。一个声明"CPU 只读、GPU 可写"的请求会被原样照办：这些页在没有写意图的情况下被 pin 住，这使内核仍愿意交出一个只读文件的共享缓存，但 GPU 收到的映射却被标记为可写。由于共享的只读文件映射由文件自身的缓存支撑，GPU 最终获得的是一条直通该缓存的写入路径，而不是写入一份副本。

补丁将两个处理器的权限绑定在一起：只要 CPU 只读，GPU 就只读。

我们通过 NVIDIA 的开源 GPU 内核模块追踪了这一缺陷。它存在于 2022 年 5 月发布的首个公开版本 515.43.04 中，并一直延续到八月补丁修复发布之前的每一个构建版本。

这意味着，在过去四年里，在一款运行于大量 Linux GPU 宿主机上的驱动中，多租户环境下的隔离形同虚设。

（由于它存在于首个开源版本中，它很可能在闭源驱动开源之前就已存在。）

请更新到 NVIDIA 驱动 610.57.04、595.91.07（或 595.44.x 分支上的 595.44.14），或 580.178.04，选择与你所在分支匹配的版本，或该分支上的任何更新版本。

我们要明确一点——除了更新之外没有实用的变通办法：该缺陷存在于驱动自身的权限推导逻辑中，不是 sysctl、seccomp 配置或 cgroup 能够封堵的，因为任何能够打开 /dev/nvidiactl 的进程都能直接到达漏洞路径。

如果你把 GPU 交给不完全信任的租户或容器，不要在未打补丁的驱动上透传 /dev/nvidia*。该 exploit 从非特权容器内部触发的效果完全相同，而且它破坏的内存与宿主机共享。

我们是在对 NVIDIA 驱动安全进行深入排查时发现 NvRoot 的。在我们负责任披露到公开修复之间的数周里，下面的检测方案已经在保护 Stealthium 的客户。这就是在任何补丁公告/可用之前就已具备的安全覆盖——当时漏洞仍然活跃、未知且未修复。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）