NVIDIA GPU Driver CVE-2026-47558

Requires an authenticated, unprivileged local user account on a Linux system running the affected NVIDIA GPU Display Driver, with access to the kernel-mode driver interface (the /dev/nvidia* device nodes reachable by normal users). The specific trigger is mishandling of 'imported memory state' in the kernel mode layer leading to a double-free, so the attacker must be able to invoke the relevant memory-import/ioctl path. Limiting factors: no remote exploitation (AV:L - physical/local session or existing shell needed), so exposure is concentrated on multi-user, shared-GPU, HPC/ML, container, or VDI hosts; reliable privilege escalation additionally depends on successful kernel heap grooming, whereas a naive trigger yields only a denial-of-service crash.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, score 7.8 HIGH) describes a locally-exploitable memory-corruption flaw requiring an already-authenticated low-privilege user, with no user interaction and full C/I/A impact - consistent with a kernel local privilege escalation. This is a genuine defense-in-depth priority on multi-user and shared-GPU systems, but the local-only attack vector (AV:L) sharply limits it versus network-reachable bugs. No EPSS score, no CISA KEV listing, and no public POC were supplied, so per the precision rules this is 'no public exploit identified at time of analysis' - meaning there is no evidence of active or automated exploitation, and the double-free (CWE-415) would require reliable heap grooming of imported memory state to weaponize into code execution rather than a mere crash. No SSVC decision data was provided. Net: a real but not emergency-tier issue - patch on normal cadence, prioritizing multi-tenant, HPC/ML, and VDI hosts where untrusted local users share the GPU driver.

A low-privileged local user on a Linux host with the NVIDIA GPU driver opens the kernel-mode device interface and issues crafted ioctl operations that mishandle imported memory state, triggering a double-free in the kernel. By grooming the kernel heap between the two frees, the attacker reclaims the freed object and corrupts kernel structures to escalate to root (or, less reliably, crashes the driver for local DoS). No public exploit code is identified at the time of analysis.