CVE-2026-52987

What it actually does

This is a Linux kernel memory-corruption flaw in the AMDGPU DRM driver. In a specific error path in amdgpu_userq_vm_validate(), the driver can call drm_exec_fini() twice on the same drm_exec object after user-page pinning fails. Because drm_exec_fini() frees internal object state and finalizes lock/acquire context, the second call can operate on already-finalized or freed state, creating a double-free/use-after-free style condition inside kernel space. Practical impact is most likely local denial of service through a kernel crash, with potential but currently unproven risk of local privilege escalation depending on kernel configuration, AMDGPU feature exposure, memory allocator behavior, and exploitability of the freed structures.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU driver functionality exposed may be vulnerable to local crashes or instability triggered by an unprivileged or GPU-capable local user/process. On shared workstations, GPU compute hosts, VDI systems, CI runners, or multi-user Linux servers with AMD GPUs, this could interrupt workloads and reduce service availability. The vulnerability is not currently in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so urgency is lower than actively exploited remote vulnerabilities; however, kernel memory-corruption bugs should still be patched during the next appropriate kernel maintenance window, especially on systems where untrusted users or workloads can access GPU devices.

How an attack unfolds

An attacker first needs local code execution on a Linux system using an affected kernel and the AMDGPU driver path that supports user queues and HMM/user-page validation. The attacker then opens the relevant DRM/GPU device interface and submits operations that cause amdgpu_userq_vm_validate() to enter the new_addition path. The attacker shapes memory mappings or resource pressure so that amdgpu_ttm_tt_get_user_pages() fails after drm_exec_fini() has already been called. The vulnerable error path then reaches cleanup code that calls drm_exec_fini() again on the same object. That second finalization may access or free stale internal kernel state, leading to memory corruption. In expected real-world outcomes, this is likely to crash the kernel or GPU driver; more advanced exploitation would require turning the double-finalization condition into controlled kernel memory corruption, which is not known to be publicly demonstrated for this issue.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the upstream AMDGPU fix corresponding to commit 2802952e4a07306da6ebe813ff1acacc5691851a or the vendor backport for this issue. No exact product package versions were provided in the input, so use the kernel advisory from the relevant Linux distribution or appliance vendor to identify the fixed kernel build. If immediate patching is not possible, reduce exposure by limiting local access to GPU DRM device nodes, removing untrusted users from groups that grant GPU access, disabling AMDGPU access for untrusted workloads, avoiding GPU passthrough to untrusted guests or containers, and disabling or blacklisting the amdgpu module only where operationally acceptable. Reboot after installing the fixed kernel so the patched kernel and driver are actually running.

How to confirm the fix worked

Confirm the system is running a kernel build that contains the vendor backport or upstream fix for the AMDGPU double drm_exec_fini() path. Validate with the distribution package changelog, kernel source package, vendor advisory, or by checking that the patched amdgpu_userq_vm_validate() error path routes directly to range cleanup after drm_exec_fini() has already been called. Confirm the running kernel with uname -a after reboot, not just the installed package version. On exposed systems, verify whether AMDGPU is loaded with lsmod or /sys/module/amdgpu, and whether local users or containers can access /dev/dri/card* or /dev/dri/renderD*. If using vulnerability scanners, ensure they check the running kernel version and vendor backport status rather than only upstream version strings.

Typical attack path

1. Gain local execution on a Linux host with an affected kernel and AMDGPU driver available.
2. Confirm access to AMD GPU DRM device nodes such as /dev/dri/renderD* or /dev/dri/card*.
3. Invoke AMDGPU user-queue or GPU memory-management operations that exercise amdgpu_userq_vm_validate().
4. Create conditions that make amdgpu_ttm_tt_get_user_pages() fail after drm_exec_fini() has already run, such as invalid mappings, resource pressure, or page-pinning failure conditions.
5. Trigger the vulnerable cleanup path, causing drm_exec_fini() to be called a second time on the same execution object.
6. Cause kernel memory corruption, typically resulting in a kernel oops, GPU driver fault, system crash, or denial of service.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs rather than network telemetry, because exploitation requires local interaction with the AMDGPU DRM driver. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs for access to /dev/dri devices, EDR process telemetry, and crash dump infrastructure such as kdump, apport, ABRT, or systemd-coredump where applicable. Search for kernel oops, panic, KASAN, KFENCE, slab corruption, use-after-free, double-free, invalid pointer, or general protection fault messages that mention amdgpu_userq_vm_validate, amdgpu_ttm_tt_get_user_pages, drm_exec_fini, drm_exec, amdgpu, or drm. Correlate timestamps with local users or container workloads opening /dev/dri/renderD* or /dev/dri/card* shortly before the crash. There are no known public exploit-specific file artifacts, command lines, registry keys, or network indicators for this CVE; repeated local GPU faulting followed by kernel memory-corruption diagnostics is the most useful detection signal.

• amdgpu_userq_vm_validate
• amdgpu_ttm_tt_get_user_pages
• drm_exec_fini
• drm_exec
• BUG: KASAN: use-after-free
• BUG: KASAN: double-free
• BUG: KFENCE: use-after-free
• general protection fault
• kernel BUG at
• Oops:
• Call Trace:
• amdgpu
• /dev/dri/renderD
• /dev/dri/card

What your security team should do

• Prioritize patching Linux systems with AMD GPUs where untrusted local users, containers, CI jobs, GPU compute workloads, VDI users, or shared desktop users can access /dev/dri devices.
• Track vendor kernel advisories and deploy the first fixed kernel package containing the AMDGPU patch; reboot systems to activate the fix.
• Until patched, restrict permissions to /dev/dri/card* and /dev/dri/renderD* and review membership in groups such as video or render.
• Review container, sandbox, and virtualization policies to avoid passing AMDGPU DRM devices into untrusted workloads.
• Monitor kernel logs for AMDGPU, DRM, KASAN, slab, use-after-free, double-free, general protection fault, or kernel oops events referencing the affected functions.
• Treat repeated GPU driver crashes or kernel oopses on shared AMDGPU systems as potentially suspicious, especially if correlated with local user activity or GPU device access.
• Because this is not currently KEV-listed, has no known exploitation, and has low EPSS, schedule broadly according to kernel maintenance policy while accelerating remediation for high-risk multi-user GPU systems.