NvRoot and ForgePtr: Two NVIDIA Linux Driver Bugs Turn a Rented GPU Slice Into Root on the Host

Security firm Stealthium disclosed two NVIDIA Linux kernel driver privilege-escalation flaws, NvRoot (CVE-2026-47591) and ForgePtr (CVE-2026-47501), that let an unprivileged user inside a GPU container gain root on the host; both have been in the open-source modules since the first open release, 515.43.04, in May 2022. NVIDIA fixed NvRoot on August 3 in drivers 610.57.04, 595.91.07 (595.44.14 on the 595.44 line) and 580.178.04, but ForgePtr was only fixed on September 9 in 615.71.09, and Stealthium confirmed root on 610.57.04, leaving admins who patched in August still exposed. NVIDIA rates both 7.8 (High) on CVSS 3.1, while Stealthium scores NvRoot at 9.3 for multi-tenant hosts, and the R590, R575, R570, R565 and older branches have no NvRoot fix at all.

Security firm Stealthium has published two NVIDIA Linux driver flaws, NvRoot and ForgePtr, that let an unprivileged user inside a GPU container take root on the host. Both are patched, but one fix arrived a month after the other, so plenty of “updated” systems are still exposed. If you rent a slice of a GPU in the cloud, the machine underneath you just got a lot less private. Stealthium, a startup that builds runtime security tooling for AI infrastructure, lifted the embargo today on two privilege-escalation bugs in NVIDIA’s Linux kernel driver: NvRoot https://stealthium.io/blog/nvroot CVE-2026-47591 and ForgePtr https://stealthium.io/blog/forgeptr CVE-2026-47501 . Phoronix https://www.phoronix.com/news/NVIDIA-NvRoot-ForgePtr picked up the disclosure this morning. Both bugs sit in the open-source NVIDIA kernel modules and, according to Stealthium, have been in the code since the very first open release, 515.43.04, back in May 2022. That is four and a half years. The researchers suspect the flaws predate the open-sourcing as well and exist in the closed driver too. NvRoot: the GPU writes where the CPU cannot Whenever a program wants the GPU to reach system memory directly, it asks the driver to pin that memory. The request carries two separate permission fields, one for the CPU side and one for the GPU side. Vulnerable drivers only looked at the CPU field when deciding what the page was allowed to do. Ask for “read-only for the CPU, writable for the GPU” and the driver honored both halves. The consequence is that a GPU kernel can overwrite the in-memory cached copy of a read-only file. Stealthium’s demonstration targets a setuid system utility: the kernel still reads the genuine setuid bit from disk and grants root privileges, then runs the tampered copy sitting in the page cache. Because the file on disk never changes, file-integrity monitoring sees nothing. The team says it built the full chain and got a root shell from a regular user account. ForgePtr: a missing error check, and Secure Boot goes away ForgePtr is, in Stealthium’s own words, “almost boring”. In the driver’s event-buffer setup path, a handle supplied by the caller gets converted into a kernel pointer, and nobody checks whether that conversion succeeded. Pass a handle that does not resolve and the driver keeps your raw value as if it were a valid pointer. When the object is later freed, the kernel decrements a counter at that address. An arbitrary decrement does not sound like much, but repeating it walks a byte through every possible value, which turns it into a write-anything primitive. Paired with a separate address leak to defeat KASLR, Stealthium says it could go from an unprivileged container to root on the host, then switch off ASLR, kernel lockdown, module signing and Secure Boot’s runtime enforcement, and load an unsigned kernel module. Which driver do you actually need? This is where it gets messy. NVIDIA shipped the NvRoot fix on August 3 in drivers 610.57.04, 595.91.07 595.44.14 on the 595.44 line and 580.178.04. ForgePtr, however, was only fixed on September 9 in 615.71.09 , and Stealthium says it confirmed root on 610.57.04, the very release that closed NvRoot. In other words, an admin who patched for the first bug in August was still exposed to the second. NVIDIA rolled both into its September 30 security bulletin, which GamingOnLinux covered https://www.gamingonlinux.com/2026/09/nvidia-security-bulletin-for-sept-30-notes-many-gpu-issues/ at the time, and Debian and Ubuntu now track the CVEs. Stealthium also notes that, at the time of writing, the R590, R575 and R570 branches, along with R565 and everything older, have no NvRoot fix at all. NVIDIA rates both issues 7.8 High on CVSS 3.1. Stealthium argues that is too low for multi-tenant hosts, scoring NvRoot at 9.3, and its reasoning is hard to argue with: on a “neocloud” node, one tenant with root can read the next tenant’s model weights and live inference data. Neither bug has a workaround short of updating, because anything that can open the NVIDIA device nodes reaches the vulnerable code. If you pass NVIDIA devices into containers you do not fully trust, update to 615.71.09 or later before doing anything else. For a home gaming PC, the risk is much lower, since an attacker already needs a local account. Still, a desktop Linux box sitting on an older branch is worth a driver update this week. And there is more coming: Stealthium says it has over 25 further High or Critical findings across NVIDIA’s AI runtime stack, still under responsible disclosure.