CVE-2026-80539 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: disallow multiple FENCE chunks in one submit
amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first.
amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit.
Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc ("drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit") did for p->bo_list.
(cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel's AMDGPU driver contains a resource management flaw within the command submission parsing logic, specifically in the amdgpu_cs_pass1 function. This vulnerability arises from an insufficient validation mechanism that fails to reject duplicate chunk identifiers during GPU command buffer processing. When a user-space application submits a command list containing multiple chunks of type AMDGPU_CHUNK_ID_FENCE, the kernel iterates through these chunks and processes each one independently without verifying if a FENCE chunk has already been encountered in the same submission. This lack of uniqueness enforcement allows an attacker to craft malicious submissions that exploit the driver's internal state handling for user fence buffers.
The technical core of this vulnerability lies in how the driver manages buffer object references associated with user fences. The parser structure maintains a single-slot field, p->uf_bo, designed to hold a reference to exactly one buffer object representing the user fence. When the first FENCE chunk is processed, amdgpu_cs_p1_user_fence correctly increments the reference count on the specified buffer object and stores its pointer in this slot. However, when a second or subsequent FENCE chunk appears in the same submission, the function executes again for that duplicate entry. This results in referencing a new buffer object and overwriting p->uf_bo with it, but critically, the driver fails to decrement the reference count on the previously held buffer object before making this switch.
This logic error leads directly to a persistent resource leak classified as CWE-401: Missing Release of Resource after Effective Lifetime. Because only the final value in p->uf_bo is released during parser cleanup via amdgpu_cs_parser_fini, every FENCE chunk except the last one leaves its associated buffer object with an unreleased reference count. These leaked references persist beyond the closure of the file descriptor and even after the process that created them has terminated. Consequently, the affected buffer objects cannot be freed by the kernel's memory management subsystem, leading to a gradual accumulation of unmapped but still referenced GPU memory resources.
The operational impact of this vulnerability is primarily denial of service through resource exhaustion. An attacker can repeatedly submit malicious command lists containing multiple FENCE chunks to systematically leak GPU buffer object references. Over time, this depletes the available VRAM or system memory reserved for GPU operations, potentially causing performance degradation, application crashes, or a complete hang of the graphics subsystem if sufficient resources are exhausted. While direct code execution is not implied by this specific flaw, the ability to exhaust kernel-managed resources can destabilize the entire operating environment and disrupt other users on shared systems.
To mitigate this vulnerability, developers must enforce strict uniqueness constraints on chunk identifiers within individual command submissions. The fix involves modifying amdgpu_cs_pass1 to track whether a FENCE chunk has already been processed in the current submission context. If a duplicate AMDGPU_CHUNK_ID_FENCE is detected, the driver should immediately reject the entire command submission with an appropriate error code rather than proceeding with parsing. This approach mirrors existing security hardening measures implemented for BO_HANDLES chunks, ensuring consistent validation logic across different types of GPU resource submissions. System administrators and users relying on affected kernel versions should apply vendor-provided patches that incorporate this duplicate-checking logic to prevent further reference leaks.