{"slug": "from-rent-to-root-introducing-nvroot", "title": "From Rent to Root: Introducing NvRoot", "summary": "Security researchers at Stealthium built a working exploit for NvRoot (CVE-2026-47591), an NVIDIA driver local privilege escalation flaw that lets an unprivileged user gain root by making a GPU write to a read-only file, confirmed on driver 610.43.02 and fixed in 610.57.04. The bug lets an attacker overwrite the in-memory copy of a setuid binary such as /usr/bin/su with a GPU write, and because the poisoned memory is shared with the host, an unprivileged container with GPU access can compromise the host and other tenants on rented multi-tenant GPUs. NVIDIA rates the flaw CVSS 7.8 High, though Stealthium recommends treating it as Critical in multi-tenant environments and says it holds 25+ further High or Critical vulnerabilities across the AI runtime stack under responsible disclosure.", "body_md": "*NvRoot (CVE-2026-47591) is an NVIDIA driver local privilege escalation vulnerability found by the Stealthium team. We built a working exploit to demonstrate the bug and confirm root, and reported it to NVIDIA. We also built detection for the bug’s exploitation, live before the patch landed. We’re publishing today enough to understand and defend against it: no proof-of-concept, and some specifics held back. Under responsible disclosure, we have 25+ further High or Critical vulnerabilities across the AI runtime stack.*\n\nRent a slice of a GPU. And if it’s on a vulnerable release, with this bug, you can get root on the host. Next door’s environment, from model weights to live inference, all available. Welcome to NvRoot.\n\nThe fact is, GPU drivers frequently partake in actions that would make security engineers nervous elsewhere. They take memory belonging to an unprivileged process and let a second processor, the GPU, read and write it directly. That’s a security model that only works if the driver is meticulous about *which* memory, and about who is allowed to do *what* to it.\n\n**In NvRoot (CVE-2026-47591) an NVIDIA driver call trusts the wrong permission field, and an unprivileged user becomes root. For multi-tenanted GPU environments, made popular by neoclouds, that’s game over. Let’s dive in.**\n\nA single pin request, with two permission fields set against each other, hands GPU write access to a file the caller can only read. Aim it at a world-readable setuid binary like `/usr/bin/su`, overwrite its in-memory copy with a payload, and run it: the kernel honors the real setuid bit and loads your bytes instead. One ioctl > one GPU write > root.\n\nNotably, none of this smells like an exploit. No kernel memory corrupted, no symbol resolved, no offset guessed, no race to win. The attacker makes a pin call like every CUDA program makes and a GPU write like every CUDA program makes. On an affected driver the mapping comes back writable. The bug is deterministic, kernel-version independent, and works the same from inside an unprivileged container as it does on a bare host.\n\n## A Big Bug\n\nNvRoot boils down to: on vulnerable drivers, **GPUs can write to read-only files.** Below is how that translates to root.\n\n### Becoming Root\n\nWe reckon the natural and known (read: malicious) thing to do is poison a setuid program. Overwrite the in-memory copy of something like `/usr/bin/su` with a small payload and run it. The kernel reads the real, untouched setuid bit from disk and grants root, then executes the copy we’ve rewritten in memory. Note that as the file on disk never changes, file-integrity checks would see nothing move. We built this end to end and watched it hand back a root shell.\n\n*An unprivileged user (uid 1001) turns /usr/bin/su into a GPU-writable surface, overwrites its cached copy, and execs into a root shell.*\n\nConfirmed to root on driver 610.43.02, and confirmed fixed on 610.57.04, where the write is rejected at pin time.\n\nAs for where a local-root bug becomes a problem for anyone on either side of rented multi-tenant GPUs…\n\nThe memory NvRoot poisons is shared with the host.\n\nFrom an unprivileged container with GPU access (which you can buy as a neocloud customer), that is a host-level compromise: the poisoned binary is the one the host and every other tenant execute. The attack crosses the container boundary exactly as it crosses the user boundary on bare metal.\n\nNVIDIA has this vulnerability scored as CVSS 7.8 High. Though, clearly per above, in multi-tenanted environments this essentially means rent = root. As such, in those environments we recommend that this be treated as Critical.\n\n## How The Bug Works\n\nProcesses ask the driver to pin memory so the GPU can reach it. The request carries two separate permissions: one for what the CPU side may do with the memory, and one for what the GPU side may do. They are meant to be independent, and both enforced.\n\nVulnerable drivers derive the actual page permission from the CPU field alone and never check across the aisle. A request that says \"CPU read-only, GPU writable\" is honored as written: the pages are pinned without write intent, which keeps the kernel willing to hand back a read-only file's shared cache, yet the mapping the GPU receives is marked writable. Because a shared read-only file mapping is backed by the file's own cache, the GPU ends up with a write path straight into it rather than into a copy.\n\nThe patch fix couples the two PUs: GPU read-only whenever CPU is read-only.\n\n## The Bug’s Not New\n\nWe traced this flaw through NVIDIA's open GPU kernel modules. It’s present in the very first public release, 515.43.04 from May 2022, and has remained through every build before the patch fix shipped in August.\n\nThat’s unenforceable isolation in multi-tenanted environments for the last four years in a driver that runs on an enormous share of Linux GPU hosts.\n\n(Because it’s in the first open release, it likely predates open-sourcing in the closed driver too.)\n\n## What to Do\n\nUpdate to NVIDIA driver 610.57.04, 595.91.07 (or 595.44.14 on the 595.44.x line), or 580.178.04, whichever matches your branch, or any later release on it.\n\nWe want to be clear - there’s no practical workaround short of updating: the defect is in the driver's own permission-derivation logic, not something a sysctl, seccomp profile, or cgroup can close off, since any process that can open `/dev/nvidiactl` reaches the vulnerable path directly.\n\nIf you hand GPUs to tenants or containers you do not fully trust, do not pass `/dev/nvidia*` through on an unpatched driver. The exploit works identically from inside an unprivileged container, and the memory it corrupts is shared with the host.\n\n## NVIDIA Timeline\n\n- **August 3, 2026:** NVIDIA ships the fix in driver versions 610.57.04, 595.91.07, and 580.178.04.\n- **September 30, 2026:** NVIDIA publishes its security bulletin, assigns CVE-2026-47591, and notifies of covered branches of versions.\n\n## Catching NvRoot\n\nWe found NvRoot while doing a deep-dive on NVIDIA driver security. Through the weeks between our responsible disclosure and the public fix, the detection below was already protecting Stealthium customers. That’s security coverage ahead of any patch advisory / availability, when the bug was live, unknown, and unfixed.\n\nNvRoot is almost indistinguishable from legitimate CUDA. It pins host memory the way every zero-copy workload does, and writes it with a normal kernel launch. No socket, no credential, no dropped file, no kernel corruption to trip a tripwire. Traditional tools are unable to see this exploit as it unfolds in AI runtime.\n\nStealthium instruments the NVIDIA driver and CUDA runtime from the kernel. For this class of attack, there’s a few things to hunt for:\n\n- **Contradictory pins:** A request that marks a region read-only for the CPU but writable for the GPU is the exploit's signature.  It’s a contradiction no legitimate workload would ask for, visible at the driver boundary as it arrives.\n- **Writes that should not exist:** A GPU-writable mapping landing on the cached copy of a setuid, root-owned file is not something a normal workload does. Seen below the CPU, it is an alert on its own.\n- **Boundary crossings:** The poisoned memory is shared with the host. Stealthium carries the node's tenancy layout as first-class telemetry, so \"a container just made a host-shared setuid binary GPU-writable\" arrives as one finding rather than something reconstructed afterward.\n\nThe same instrumentation that catches NvRoot surfaces other AI runtime attacks. Just a few include: cross-tenant side channels, unauthorized inference on a rented slice, model-weight and KV-cache exposure, and mining hidden inside a legitimate-looking allocation. Traditional tooling misses all of them for the same reason it misses this one: they don’t look below the CPU.\n\nIf you’d like to read our other research, you can [head to our other local privilege escalation vulnerability](https://stealthium.io/blog/forgeptr) we’re releasing information about today, or [head here to read about a model poisoning attack](https://stealthium.io/blog/hands-off-detecting-model-weight-tampering) that traditional tools miss completely.\n\n## Methods & Attribution\n\nVulnerability found by Stealthium Senior Security Researcher: Branislav Brzak\n\n**Affected range:** present in source in every open-source driver release from 515.43.04 (2022-05-09) through the builds before 610.57.04 / 595.91.07 / 580.178.04; runtime-confirmed to root on 610.43.02. Fixed in 610.57.04, 595.91.07 (and 595.44.14 on the 595.44.x line), 580.178.04, and later releases on those branches. At the time of writing, every release on the R590, R575, and R570 branches, and all of R565 and earlier, remains unpatched.\n\n**Classification:** CVE-2026-47591, CWE-863 (Incorrect Authorization).\nNVIDIA scores this 7.8 High with CVSS 3.1. Our assessment, which accounts for impact beyond the vulnerable component, is 9.3 Critical under CVSS 4.0 (8.8 under 3.1 with scope change). On multi-tenant hosts, aka if you are renting or offer multi-tenanted GPU environments, treat it as Critical.\n\n**Requires:** a CUDA-capable NVIDIA GPU and an unprivileged local account (no special group, no `CAP_SYS_ADMIN`). The defect is in shared RM code, so both the open and proprietary driver builds are affected, on any supported GPU architecture.\n\n**References:** [NVIDIA Security Bulletin, September 2026](https://nvidia.custhelp.com/app/answers/detail/a_id/5861) · [CVE-2026-47591 (NVD)](https://nvd.nist.gov/vuln/detail/CVE-2026-47591)", "url": "https://wpnews.pro/news/from-rent-to-root-introducing-nvroot", "canonical_source": "https://stealthium.io/blog/nvroot", "published_at": "2026-11-12 00:00:00+00:00", "updated_at": "2026-11-12 14:19:15.304177+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-chips"], "entities": ["NVIDIA", "Stealthium", "NvRoot", "CVE-2026-47591", "/usr/bin/su"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/from-rent-to-root-introducing-nvroot", "markdown": "https://wpnews.pro/news/from-rent-to-root-introducing-nvroot.md", "text": "https://wpnews.pro/news/from-rent-to-root-introducing-nvroot.txt", "jsonld": "https://wpnews.pro/news/from-rent-to-root-introducing-nvroot.jsonld"}}