Look up another CVE · open CVE-2026-52987 in the interactive tracker

CVE-2026-52987

drm/amdgpu: avoid double drm_exec_fini() in userq validate

7.8 EPSS 0.2% AV:L

Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-52987 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.0.10-1	Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.10-1	Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

When new_addition is true, amdgpu_userq_vm_validate() calls drm_exec_fini(&exec) before iterating over the collected HMM ranges and calling amdgpu_ttm_tt_get_user_pages(). If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to unlock_all and calls drm_exec_fini(&exec) a second time on the same exec object. drm_exec_fini() is not idempotent: it frees exec->objects and may also drop exec->contended and finalize the ww acquire context. Route that error path directly to the range cleanup once exec has already been finalized. Issue found using a prototype static analysis tool and confirmed by code review. (cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a)

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c

What this is: RADEON and AMDGPU DRM DRIVERSMAINTAINERS section matched on drivers/gpu/drm/amd/ · amd-gfx@lists.freedesktop.org · Supported
Kernel module: amdgpu

Check it on the machine

grep -w CONFIG_DRM_AMDGPU /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w amdgpu

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.

bookworm, trixie?
forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x

?: not established - no Makefile entry for the affected file
M: a module where it is built at all; some flavours do not build it

Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.

Build switch: CONFIG_DRM_AMDGPU

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-06-24 (4 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.18%, higher than 6.6% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: drivers/gpu

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.19	7.0.10	c7c3ae7c01e5
6.19	7.1	508babf31036

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The vulnerable path is reached through AMDGPU DRM ioctls on a local DRM render/primary device, not through network, adjacent, or physical input.
AC:LAttack complexity, low: A local attacker can create and map userptr-backed AMDGPU BOs and then trigger user queue VM validation; the failing `amdgpu_ttm_tt_get_user_pages()` path can be induced with attacker-controlled invalidated or unsuitable user memory.
PR:LPrivileges required, low: The ioctl is registered with `DRM_AUTH|DRM_RENDER_ALLOW`, so a render-node client can reach it without root, DRM master, or real administrative capabilities.
UI:NUser interaction, none: No victim action is required after the local attacker runs the ioctl sequence.
S:UScope, unchanged: The corruption occurs inside the kernel driver and any resulting privilege escalation or crash remains within the same kernel security authority.
C:HConfidentiality impact, high: The bug double-finalizes a `drm_exec`, causing use-after-free/double-free of kernel-managed objects; such memory corruption can reasonably be leveraged for kernel memory disclosure.
I:HIntegrity impact, high: The same use-after-free/double-free condition can corrupt allocator and object state, making arbitrary kernel memory modification or control-flow compromise defensible.
A:HAvailability impact, high: Even without full exploitation, double-free/use-after-free in kernel cleanup paths can oops, panic, or otherwise crash the system.