CVE-2026-63880
Received Received - Intake

Memory Leak in AMDGPU Linux Kernel Driver

Publication date: 2026-07-19

Last updated on: 2026-07-19

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-19
Last Modified
2026-07-19
Generated
2026-07-20
AI Q&A
2026-07-19
EPSS Evaluated
N/A
NVD
CVE-2026-63880
EUVD
EUVD-2026-45765

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 7.0.0 (inc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a memory allocation failure in the AMDGPU driver. When the AMDGPU_GEM_OP_GET_MAPPING_INFO operation fails to allocate memory, it skips proper cleanup of three resources: a drm_gem_object reference, a drm_exec lock on the GEM object, and a drm_exec lock on the per-process VM root page directory. This leads to a lock leak, causing subsequent operations on the same GPU context to block indefinitely.

Detection Guidance

This vulnerability is specific to the Linux kernel's AMDGPU driver and may not have direct network detection methods. Monitor for processes stuck in 'D' state during GPU operations. Check kernel logs for ENOMEM errors in AMDGPU-related ioctls. Commands like 'dmesg | grep -i amdgpu' or 'journalctl -k | grep -i amdgpu' may reveal errors.

Impact Analysis

This vulnerability allows an unprivileged local attacker with access to /dev/dri/renderD* to cause a denial of service against their own GPU context. The affected process may become unresponsive and require a system reboot to recover, as the lock leak prevents normal cleanup even after the process is terminated.

Compliance Impact

This vulnerability does not directly affect compliance with GDPR, HIPAA, or similar standards as it is a local denial-of-service issue in the Linux kernel's AMDGPU driver. It does not involve data breaches, unauthorized access, or privacy violations that these regulations typically address.

Mitigation Strategies

Apply the kernel patch that routes the ENOMEM error through the cleanup path. Update to a kernel version containing the fix (e.g., 7.0.0-10 or later). Restrict access to /dev/dri/renderD* devices to trusted users only. Monitor for processes in 'D' state and reboot affected systems if necessary.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-63880. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart