CVE-2026-52987

In the Linux kernel, the following vulnerability has been resolved:

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

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)

Weakness

The product attempts to close or release a resource or handle more than once, without any successful open between the close operations.

Affected Software

Extended Description

Code typically requires “opening” handles or references to resources such as memory, files, devices, socket connections, services, etc. When the code is finished with using the resource, it is typically expected to “close” or “release” the resource, which indicates to the environment (such as the OS) that the resource can be re-assigned or reused by unrelated processes or actors - or in some cases, within the same process. API functions or other abstractions are often used to perform this release, such as free() or delete() within C/C++, or file-handle close() operations that are used in many languages. Unfortunately, the implementation or design of such APIs might expect the developer to be responsible for ensuring that such APIs are only called once per release of the resource. If the developer attempts to release the same resource/handle more than once, then the API’s expectations are not met, resulting in undefined and/or insecure behavior. This could lead to consequences such as memory corruption, data corruption, execution path corruption, or other consequences. Note that while the implementation for most (if not all) resource reservation allocations involve a unique identifier/pointer/symbolic reference, then if this identifier is reused, checking the identifier for resource closure may result in a false state of openness and closing of the wrong resource. For this reason, reuse of identifiers is discouraged.

Potential Mitigations

References

• https://git.kernel.org/stable/c/508babf310365f1107a2e8831c267c292a286818
• https://git.kernel.org/stable/c/c7c3ae7c01e5a0742b93cb9b40800bdd7f811e38
• https://access.redhat.com/security/cve/CVE-2026-52987
• https://bugzilla.redhat.com/show_bug.cgi?id=2492365
• https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52987.json