CVSS VectorNVD
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionNVD
Out of bounds write in AMD AMDGV_CMD_GET_DIAG_DATA ioctl handler could allow a local user to escalate privileges via remote code execution.
AnalysisAI
Buffer overflow in AMD GPU driver IOCTL handler enables local privilege escalation to root on Linux systems running AMD Instinct or Radeon Pro GPUs. Authenticated local users with low privileges can exploit an out-of-bounds write vulnerability in the AMDGV_CMD_GET_DIAG_DATA IOCTL to achieve arbitrary kernel code execution. EPSS data not available; no public exploit or CISA KEV listing identified at time of analysis, suggesting limited active exploitation despite high CVSS 8.5 severity.
Technical ContextAI
This vulnerability affects the AMD GPU driver kernel module, specifically the IOCTL (input/output control) handler for the AMDGV_CMD_GET_DIAG_DATA diagnostic command. IOCTL handlers are privileged kernel-space interfaces that allow user-space applications to communicate with device drivers. The CWE-787 classification indicates an out-of-bounds write vulnerability, where the driver writes data beyond allocated buffer boundaries during diagnostic data retrieval operations. Affected products span AMD's data center GPU portfolio including Instinct MI200/MI300 series accelerators (MI210, MI250, MI300A, MI300X, MI308X, MI325X) and Radeon Pro virtualization GPUs (V620, V710). These are high-performance computing and AI acceleration products typically deployed in enterprise data centers, cloud infrastructure, and virtualized environments where GPU passthrough or SR-IOV configurations may be used.
RemediationAI
Apply AMD-released driver updates specified in Security Bulletin AMD-SB-6027 (https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6027.html). Organizations should prioritize patching systems in multi-user environments where local access is granted to multiple accounts. As interim mitigation where patching cannot be immediately deployed, restrict local user access to affected GPU systems through operating system access controls, disable diagnostic IOCTL interfaces if operationally feasible via kernel module parameters or SELinux/AppArmor policies (noting this may impact legitimate monitoring tools), and enhance monitoring for unusual privilege escalation attempts or unexpected kernel module interactions. For virtualized GPU deployments using SR-IOV or GPU passthrough, consider temporarily removing GPU assignments from untrusted guest VMs until patching is complete, though this impacts workload functionality. In shared HPC clusters, implement stricter job scheduler policies to isolate untrusted users until remediation. These compensating controls reduce attack surface but do not eliminate the vulnerability and should be treated as temporary measures pending full driver updates.
More from same product – last 7 days
VM escape in Kata Containers allows any Kubernetes user with pod-creation rights to break out of the VM sandbox and gain
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix watch_id bounds checking in debug a
In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2025-209879
GHSA-84gc-54qf-v3jp