NVIDIA Linux GPU driver: read-only memory permissions are not preserved, allowing unprivileged writes

CVSS 7.8CVE-2026-47489NVIDIA / GPU stack+1 more CVEscurated

Impact

An unprivileged local user holding a GPU device node can write to memory the driver mapped read-only, because the permission bits are not carried through. On a GPU node that means tampering with state the driver trusts, which is the usual first step to kernel code execution and full host root. NVIDIA split this across two ids in bulletin 2026/5861 (CVE-2026-47489 and CVE-2026-47595) with the same score and the same driver update; both are the same loss-of-permission class in the Linux kernel mode layer. On a shared node, any tenant container that was given /dev/nvidia* is in a position to try it.

Who can reach it

Local, no authentication beyond a shell or container on the node. Any tenant with a GPU pod, since the GPU device nodes are passed into the container, or any local user with access to /dev/nvidia*.

What to do

Install the driver branch update listed in NVIDIA bulletin 2026/5861; the record does not name fixed version numbers, so take them from the bulletin. The fix is in the kernel module, so every GPU node has to be drained of workloads and the modules reloaded; in practice operators reboot, which on a packed training fleet means scheduling the node out for the duration of the job.

Also covers 1 CVE

The vendor assigned a separate id to each affected code path. They share this advisory, this score and this fix, so they are one entry here.

CVE-2026-47595

References

https://nvd.nist.gov/vuln/detail/CVE-2026-47489 https://github.com/NVIDIA/product-security/tree/main/2026/5861 https://www.cve.org/CVERecord?id=CVE-2026-47489

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.