CVE-2026-52987: Linux Kernel Privilege Escalation Flaw

CVE-2026-52987 Overview

CVE-2026-52987 is a Linux kernel vulnerability in the AMD GPU (amdgpu) Direct Rendering Manager driver. The flaw occurs in the amdgpu_userq_vm_validate() function, where the drm_exec_fini() cleanup routine can be invoked twice on the same execution context. When new_addition is true and amdgpu_ttm_tt_get_user_pages() fails, the error path jumps to unlock_all and calls drm_exec_fini(&exec) a second time. Because drm_exec_fini() is not idempotent, this leads to a double-free condition on exec->objects and corruption of the ww acquire context state.

Critical Impact
Local attackers with access to the AMD GPU device interface could trigger memory corruption in kernel space through repeated invocation of the affected validation path.

Affected Products

Linux kernel drm/amdgpu driver (mainline tree prior to fix commit 2802952e4a07)
Stable kernel branches receiving the cherry-picked backport
Distributions shipping vulnerable AMD GPU driver builds

Discovery Timeline

2026-06-24 - CVE-2026-52987 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52987

Vulnerability Analysis

The vulnerability resides in the user-mode queue (userq) validation path of the amdgpu kernel driver. The amdgpu_userq_vm_validate() function manages buffer object reservations through the DRM execution context API. When the caller adds new buffer objects to the validation list (new_addition is true), the function finalizes the drm_exec context with drm_exec_fini(&exec) before iterating over collected HMM (Heterogeneous Memory Management) ranges. The code then calls amdgpu_ttm_tt_get_user_pages() to pin user pages backing the buffer objects.

If amdgpu_ttm_tt_get_user_pages() returns an error in this state, control flow transfers to the shared unlock_all cleanup label. That label unconditionally calls drm_exec_fini(&exec) a second time on the already-finalized context. The function frees exec->objects, drops the exec->contended reference, and finalizes the ww_mutex acquire context. Calling it twice corrupts kernel memory and the locking subsystem state, classifying this issue as a Double Free [CWE-415] condition.

Root Cause

The root cause is a missing branch in the error handling logic. The code shares a single cleanup label (unlock_all) for both pre-finalization and post-finalization error paths. No guard prevents the second drm_exec_fini() call once the context has been released. The fix routes the post-finalization error path directly to the HMM range cleanup, bypassing the redundant teardown.

Attack Vector

The issue was found using a prototype static analysis tool and confirmed through manual code review. Triggering the path requires user-space interaction with the AMD GPU user queue interface and a failure inside amdgpu_ttm_tt_get_user_pages(). A local user with permission to submit GPU work could craft conditions that fail page pinning to reach the buggy error path. See the upstream patches at Kernel Git Commit 508babf3 and Kernel Git Commit c7c3ae7c for the exact change.

// No verified exploitation code is available for this issue.
// The vulnerability manifests in amdgpu_userq_vm_validate() when
// amdgpu_ttm_tt_get_user_pages() fails after drm_exec_fini() has
// already released the exec context. See kernel.org commits referenced above.

Detection Methods for CVE-2026-52987

Indicators of Compromise

Kernel panics, oopses, or BUG: messages referencing drm_exec_fini, amdgpu_userq_vm_validate, or amdgpu_ttm_tt_get_user_pages in dmesg and /var/log/kern.log.
KASAN (Kernel Address Sanitizer) reports flagging use-after-free or double-free conditions inside the amdgpu module.
Unexpected ww_mutex deadlock or contention warnings emitted by the kernel locking subsystem on hosts running AMD GPUs.

Detection Strategies

Inventory running kernels and compare versions against the fix commits 508babf3 and c7c3ae7c to identify unpatched systems.
Enable KASAN and lockdep in test or staging kernels to surface double-free and locking inconsistencies originating from the amdgpu driver.
Monitor for repeated GPU process crashes on workloads using user-mode queue submission paths.

Monitoring Recommendations

Forward kernel ring buffer and journald logs to a central data lake and alert on amdgpu stack traces.
Track GPU device reset counters exposed under /sys/class/drm/card*/device/ for anomalous spikes.
Correlate user-space processes interacting with /dev/dri/renderD* against kernel fault events to identify potential trigger workloads.

How to Mitigate CVE-2026-52987

Immediate Actions Required

Apply the upstream kernel patch that reroutes the post-drm_exec_fini() error path to the HMM range cleanup label.
Update to a distribution kernel build that incorporates commits 508babf310365f1107a2e8831c267c292a286818 and c7c3ae7c01e5a0742b93cb9b40800bdd7f811e38.
Restrict local access on multi-tenant systems with AMD GPUs until patched kernels are deployed.

Patch Information

The fix was cherry-picked from mainline commit 2802952e4a07306da6ebe813ff1acacc5691851a and lands in stable trees through the two referenced kernel.org commits. The patch ensures drm_exec_fini(&exec) is called exactly once per execution context by directing failures of amdgpu_ttm_tt_get_user_pages() to the range cleanup path rather than the shared unlock_all label.

Workarounds

Avoid loading the amdgpu kernel module on systems where AMD GPU acceleration is not required: modprobe -r amdgpu.
Limit access to DRM render nodes (/dev/dri/renderD*) to trusted users via group permissions or container policies.
Disable user-mode queue submission features through driver module parameters on affected kernels where supported by the distribution.

bash

# Verify the running kernel includes the fix commit
uname -r
grep -E 'drm_exec_fini|amdgpu_userq_vm_validate' /proc/kallsyms

# Restrict access to AMD GPU render nodes
sudo chgrp render /dev/dri/renderD128
sudo chmod 0660 /dev/dri/renderD128