NVIDIA GPU Display Driver - GPU firmware access control over GPU control registers: Incorrect access control in the GPU
Impact
Incorrect access control in the GPU firmware allows the CPU to reach sensitive GPU control registers it should not be able to touch, leading to privilege escalation. This is the register-level control plane of the accelerator - the surface that governs channel setup, memory-management-unit configuration and engine state, i.e. the machinery that is supposed to keep one tenant's GPU contexts from seeing another's. NVIDIA states all driver versions were affected. For an operator, this is the pre-2018 evidence that GPU isolation depends on firmware-enforced register permissions, not just on the driver, which is why 'we patched the driver' and 'the GPU is isolated' are different claims.
Who can reach it
Local - code running on the host CPU with GPU access, which on a shared node is any tenant workload holding a GPU.
What to do
Update to a fixed NVIDIA driver branch; the correction shipped as part of the driver package because the driver loads the GPU firmware, so this is a driver update rather than a separate VBIOS flash. Same operational cost as any GPU driver bump - drain the node, stop every process holding the GPU, reload the kernel module. Confidence note for anyone reconstructing this: NVIDIA's original bulletin lived on the retired nvidia.custhelp.com host, so the primary vendor page is no longer resolvable and the record has to be read from the CVE and NVD entries.
References
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.