NVIDIA Display Driver EUVD-2026-90177

Requires local, already-authenticated low-privilege access to a Linux host running the NVIDIA GPU Display Driver (kernel-mode layer); exploitation consists of repeatedly invoking a specific driver interface that emits error messages without rate limiting. Limiting factors: the attacker must already be able to execute code locally (PR:L), there is no remote or unauthenticated path (AV:L), no user interaction of a victim is involved (UI:N), and the impact is confined to availability - log/resource exhaustion DoS with no confidentiality or integrity consequence. Only the Linux driver is affected per the vendor's Linux-specific description and CPE set.

This is a genuinely low-priority issue despite a moderate 5.5 CVSS. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) is internally consistent with the description: local attack vector, low privileges already held, and a pure availability impact (C:N/I:N) - no code execution, data disclosure, or integrity loss is possible. The CWE-400 (uncontrolled resource consumption) maps cleanly to the described unrate-limited kernel logging. No EPSS score, CISA KEV listing, or public POC is present in the provided intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Real-world risk is bounded by two strong limiters: an attacker must already have local low-privilege code execution on the host, and the maximum outcome is a log-flooding/disk-exhaustion denial of service rather than privilege escalation. This contrasts sharply with sibling CVEs in the same NVIDIA bulletin 5861 that carry 7.8 RCE-class OOB/UAF impacts. No signals conflict; the only absent data (EPSS/KEV/POC) is expected for a freshly disclosed vendor-reported local DoS and does not change the assessment.

A local low-privileged user (or a process on a shared multi-tenant Linux GPU host such as a VDI or cloud-GPU node) repeatedly calls the vulnerable kernel-mode driver interface that emits error messages without rate limiting. The resulting flood of kernel log entries consumes disk space, I/O, and log-processing resources, degrading or denying service to other users on the machine. No public exploit code is identified, and exploitation requires pre-existing local access.