NVIDIA GPU Driver EUVD-2026-90173

Requires LOCAL access with an existing low-privileged account or code execution on a host running the NVIDIA GPU Display Driver (Windows or Linux); the attacker interacts with the kernel-mode driver interface to trigger the uninitialized-memory copy-back. No user interaction and no special non-default configuration are needed - the flaw is in the default kernel driver path. Limiting factors: exploitation cannot be performed remotely (AV:L), the attacker must already be authenticated/present on the machine (PR:L), and the outcome is limited to reading leaked kernel data - there is no code execution, privilege escalation, or system disruption from this bug alone.

Real-world risk is LOW-to-MODERATE despite the confirmed vulnerability. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) is internally consistent and I agree with it: exploitation requires LOCAL access with already-held low privileges (PR:L), and the only impact is information disclosure - no integrity or availability impact (I:N/A:N). There is NO EPSS score, NO CISA KEV listing, and NO public POC provided, so this is 'no public exploit identified at time of analysis.' The C:H rating reflects that leaked uninitialized kernel memory can contain sensitive data (pointers useful for KASLR defeat, cryptographic material, other processes' residual data), which is why confidentiality is High even though this is a low-severity CVE overall. No signals conflict here - all point to a low-urgency, defense-in-depth patch rather than an emergency. The most realistic value of this bug to an attacker is as an information-leak primitive chained with a separate memory-corruption bug (e.g. one of the numerous OOB-write siblings in NVIDIA bulletin 5861) to bypass kernel address randomization.

A local attacker who already has an unprivileged account or code execution on a Windows or Linux host with NVIDIA drivers issues a crafted ioctl/escape to the kernel-mode driver that returns a buffer the driver failed to fully initialize. The returned bytes contain leftover kernel heap/stack contents, disclosing pointers or sensitive data to userspace. No public exploit is identified, and the leak alone grants no code execution - it is most useful as a KASLR-defeat primitive paired with a separate write vulnerability.