NVIDIA GPU Display Driver EUVD-2026-90109

Requires the attacker to already have local access and the ability to run code as a low-privileged user or process on a host with the NVIDIA GPU Display Driver installed (Windows or Linux), and to interact with the kernel mode driver interface (device ioctl/syscall) to trigger the use-after-free. For the vGPU-specific components (Guest Driver / Virtual GPU Manager tags), the relevant deployment is NVIDIA vGPU virtualization where a malicious or compromised guest exercises the driver path. Limiting factors: attack vector is LOCAL (AV:L) with no network or remote exploitation path, so no internet-facing exposure; a low but non-zero privilege level is needed (PR:L); no user interaction is required (UI:N). There is no special non-default configuration required beyond having the affected NVIDIA driver installed, which is standard on any system using NVIDIA GPUs.

This is a genuine, actionable priority for environments running NVIDIA GPUs, though not an emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8 HIGH) describes a local, low-complexity, low-privilege use-after-free in the kernel mode layer of the GPU display driver, with full C:H/I:H/A:H impact - consistent with a local privilege escalation from a low-privileged user or process to kernel/SYSTEM. The AV:L (local) requirement is the single biggest risk-limiter: there is no remote network path, so an attacker must already have code execution on the host (or a foothold in a VM guest for the vGPU/Guest Driver variant). No EPSS score, CISA KEV listing, or public POC is present in the supplied data, so exploitation status is 'no public exploit identified at time of analysis' - this is not confirmed to be exploited in the wild. There is no SSVC decision data provided. The signals are internally consistent (vendor-reported by NVIDIA, CWE-416 use-after-free matches the described UAF and the memory-corruption tag), so no conflict needs flagging beyond the general caveat that a kernel UAF's true exploitability for code execution vs. mere DoS depends on the specific object lifecycle, which the advisory does not detail. Overall: patch-worthy local EoP, high because of ubiquitous GPU footprint, but gated behind requiring an existing local foothold.

A low-privileged local user or a compromised sandboxed process on a Windows or Linux workstation issues crafted ioctl/syscall requests to the NVIDIA kernel mode driver, triggering a use-after-free on a freed kernel object. By grooming kernel heap allocations to reclaim the freed memory, the attacker gains kernel-mode code execution and escalates to SYSTEM/root; in the vGPU deployment, a malicious guest driver could similarly attack the Virtual GPU Manager. No public exploit code is identified at time of analysis, and exploitation requires prior local access.