NVIDIA GPU Driver EUVD-2026-90129

Requires local access to a system running the NVIDIA GPU Display Driver for Linux and an existing unprivileged (PR:L) account able to interact with the driver interface; no user interaction is needed (UI:N) and no special non-default configuration is indicated. Exploitation is limited to attackers who can already execute code locally on the GPU host - there is no network vector - making the realistic exposure highest on shared/multi-tenant GPU deployments (VDI, cloud GPU instances, HPC nodes) where untrusted users share a driver instance, and lowest on single-user workstations.

This is a genuine but not emergency-grade issue. The CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a local, low-privilege attacker on a Linux host with an NVIDIA GPU driver installed achieving high confidentiality/integrity/availability impact via a kernel-related use-after-free (CWE-416). The HIGH severity is driven entirely by impact, not by reach: attack vector is LOCAL and requires existing low-privilege access (PR:L), so there is no remote or unauthenticated exposure despite the 'RCE' tag. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent exploitation; the report is vendor-originated (NVIDIA, bulletin 5861) with a patch available. SSVC inputs (exploitation status, automatable) are absent. The 'RCE' tag overstates reach - code execution here is local privilege escalation, not network RCE (AV:L, not AV:N) - verify against NVIDIA's advisory. Net: a real local-privilege-escalation/DoS priority for multi-tenant, VDI, and cloud-GPU Linux hosts where untrusted users share a GPU node, but lower priority for single-user workstations. Consistent with sibling bulletin-5861 CVEs [[cve-2026-47569]] and [[cve-2026-47559]].

A low-privileged local user on a Linux system with the NVIDIA GPU driver installed (e.g., a tenant on a shared GPU/VDI/cloud instance) issues crafted ioctl or API calls to the driver that trigger a use-after-free on a kernel-mode object. By grooming the freed allocation, the attacker corrupts memory to escalate privileges to root, crash the host (DoS), or read kernel/other-process memory. No public exploit code is identified at time of analysis, and the attacker must already have local access.