Two flaws in NVIDIA’s Linux driver have broken cloud GPU isolation for four years

September 30, 2026. The NVD publishes two advisories on NVIDIA’s Linux GPU driver, both rated 7.8 (high). November 12, 2026. Researcher Stealthium lifts the embargo and names them: ForgePtr and NvRoot. Why it matters: these flaws have lived in the NVIDIA open kernel modules for four years, and they break precisely the isolation promise that underlies renting GPUs in the cloud.

Two flaws, two broken isolation promises

ForgePtr is tracked as CVE-2026-47501. In the NVD description it is an out-of-bounds write (CWE-787) in the driver’s kernel-mode layer, triggered by supplying mismatched memory buffers during event buffer setup. The consequence Stealthium describes is blunter: an unprivileged process in a GPU container can become root on the host.

NvRoot, tracked as CVE-2026-47591, is an authorization flaw. The NVD describes it as a bypass of read-only memory protection due to incorrect authorization (CWE-863): an unprivileged user gains write access to memory marked read-only. In infrastructure terms: the GPU can rewrite files the OS has marked read-only, from any tenant on the node.

These are two faces of the same disease: the boundary that separates one tenant from another — and a container from its host — is not watertight at the graphics-driver layer. And that boundary is exactly what a customer buys when renting a GPU slice.

A gap between the official rating and the real impact

The nuance is worth stating, because it changes how you read the risk. The official CVSS vector for both flaws is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: local vector, low privileges, unchanged scope. In other words, the NVD — echoing the vendor’s assessment — classifies these as privilege escalations within a single security context, which is what justifies the 7.8 rather than a critical rating.

Stealthium’s write-up tells a different story: a container escape to host root, and cross-tenant file writes. If the described impact holds, the real scope is changed, not unchanged — and the operational score in a multi-tenant environment approaches critical. This is the classic gap between a vendor’s conservative rating and a third-party researcher’s proof, and it should be kept in mind before triaging your fleet.

Phoronix, relaying the disclosure, sums up the stakes in one sentence: the flaws are “particularly volatile for those renting GPU slices in the cloud.” GPU cloud providers — running multiple customers on a single physical node — are first in line.

Four years of exposure, fixes spread across branches

Both flaws have lived in the NVIDIA open kernel modules for roughly four years — a duration that says two things: the attack surface of a graphics driver is deep, and its security review rate has been thin until recently.

Fixes exist, but they are spread across several driver branches, which complicates triage:

• NvRoot is fixed by drivers 610.57.04, 595.91.07, and 580.178.04;
• ForgePtr is fixed by 615.71.09 — a branch whose functional changes we covered in September, not knowing at the time it also carried this security fix.

The scattering matters. An operator following a long-term-support branch (say 580.x or 595.x) is not necessarily covered against ForgePtr, and must check whether they also need to move to a newer branch. Reading your driver vendor’s advisory carefully is not optional.

The “open kernel modules” detail matters for triage. NVIDIA has spent the last few years moving its Linux stack from the proprietary module to the open kernel modules (nvidia-open), which increasingly ship as the default on newer GPUs. The flaws live in that open code — which means the people who can now read it are not only NVIDIA’s engineers but also the researchers who found the bugs. If your fleet runs the proprietary module, do not assume you are safe: the shared user-space components and the fixed driver branches span both, so verify your exact binary against the list above rather than trusting the module flavor.

And twenty-five more disclosures to come

The most worrying part comes at the end of the announcement. In a message to Phoronix, Stealthium says it has 25 more security disclosures in reserve, this time targeting the NVIDIA AI runtime stack. In other words, ForgePtr and NvRoot are only the first two rounds of a larger stock, and the window that just opened will not close this week.

That is the second lesson for an SRE or CISO: beyond these two CVEs, expect a series of patches across the NVIDIA ecosystem — the driver, but also components of the CUDA stack and inference runtimes — in the coming weeks. The right posture is not “patch these two” but “re-activate continuous GPU driver monitoring.”

What it means for GPU-cloud operators

These two flaws hit one business model first: renting GPU slices, where several customers share the kernel of a single node. That is where the gap between the 7.8 rating and Stealthium’s proof is expensive — a container escape to host root, in an environment where the host belongs to the provider rather than the customer, breaks the very promise that justifies sharing.

The operational point that follows is rarely spelled out: the tenant does not choose the driver version. In a GPU cloud, the provider decides which binary is loaded, and therefore the exposure of all its customers. The responsibility — and the urgency — therefore sits first with GPU-cloud operators and teams that pool nodes internally, before it reaches the end consumer.

For a consumer, the question to ask a provider is simple and verifiable: “which driver version runs on the nodes I rent, and does it cover 615.71.09?” The answer is a decent test of the provider’s security maturity.

Check and fix

The check is a single command. It prints the installed driver version, to compare against the fixed branches above.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

If the returned version predates the fixed branches — and especially if it is below 615.71.09 — you are in the vulnerable range. The real fix is upgrading the driver through your distribution’s repository, or through the NVIDIA installer for fleets that manage it manually. On shared nodes, triage must cross driver version with isolation model: if your GPU containers share the host kernel, exposure to ForgePtr is direct.

A reminder for Kubernetes environments: driver updates require draining the affected nodes, since the kernel module reloads on reboot. Plan the rollout by draining GPU nodes one at a time, rather than improvising a hot update.

Verdict

If you run NVIDIA GPUs — and especially if you rent GPU slices or host multiple tenants on one node — upgrade the driver to a fixed branch before your next maintenance window, treating ForgePtr (615.71.09) as the priority because it enables container escape to the host. The official 7.8 score understates the real impact in shared environments, and the 25 announced disclosures offer no reason to wait. If you follow an LTS branch, verify explicitly that it covers both CVEs — the scattering of fixes across branches makes the “I’m up to date so I’m covered” assumption false here.

References

• Phoronix — “NVIDIA NvRoot & ForgePtr Vulnerabilities Published For Linux Driver, 25 More Coming” (Michael Larabel, November 12, 2026)
• NVD — CVE-2026-47501 (published September 30, 2026)
• NVD — CVE-2026-47591 (published September 30, 2026)
• ETTAYEB — “NVIDIA 615.71.09 brings Reflex to Vulkan games under Proton and cgroup memory partitioning”