CVE-2026-80618 in Linuxinfo

Summary

by MITRE • 08/28/2026

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

drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free

amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap BOs (which are pinned at allocation time) before checking whether the BO is still mapped to the GPU. When the BO is still mapped, the function returns -EBUSY and leaves the BO alive, but it has already been unpinned. The BO is then unpinned again when it is finally freed during process teardown, triggering a ttm_bo_unpin() underflow warning:

WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm]
Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]
RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm]
Call Trace: amdgpu_bo_unpin+0x1a/0x90 [amdgpu]
amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu]
amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu]
kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu]
kfd_process_wq_release+0x109/0x1b0 [amdgpu]
process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 kthread+0xdd/0x100 ret_from_fork+0x29/0x50

Move the unpin after the mapped_to_gpu_memory check so it only happens once we are committed to freeing the BO.

(cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75)

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 08/28/2026

The Linux kernel's Direct Rendering Manager subsystem, specifically within the AMDGPU driver and its Kernel Fusion Driver interface for managing GPU memory, contains a logic error in the function amdgpu_amdkfd_gpuvm_free_memory_of_gpu. This vulnerability manifests as an improper resource management flaw where buffer objects representing DOORBELL or MMIO remap regions are incorrectly unpinned prior to verifying their current mapping status with the GPU hardware. Buffer pinning is a critical mechanism in kernel graphics drivers that prevents memory pages from being swapped out or reclaimed by the system, ensuring stable access for both CPU and GPU operations. When these specific buffer objects are allocated, they are pinned to guarantee consistent physical address mappings required for low-latency communication between the host processor and the AMDGPU hardware components.

The operational flaw occurs during the cleanup phase of a process that has utilized KFD resources. The function amdgpu_amdkfd_gpuvm_free_memory_of_gpu is responsible for releasing GPU memory associated with a specific GPU context. In the flawed implementation, the code sequence first calls ttm_bo_unpin to release the pin on DOORBELL and MMIO buffer objects. Immediately following this action, the driver checks whether these buffers are still mapped into the GPU's address space. If they remain mapped, indicating that the hardware is likely still referencing them or that the unmap operation has not completed successfully, the function returns an error code -EBUSY to indicate that the resource cannot be freed at this moment. Crucially, because the pin was already removed before this check, the buffer object remains in a live state but without its necessary memory reservation.

This sequence creates a dangerous race condition and reference counting anomaly during subsequent process teardown phases. When the kernel eventually attempts to fully free these orphaned or improperly managed buffer objects later in the lifecycle of the process cleanup workqueue, it invokes ttm_bo_unpin again on buffers that are no longer pinned. This results in an underflow warning within the TTM (Translation Table Maps) memory management subsystem, specifically at amdttm_bo_unpin. While this may not immediately cause a system crash or privilege escalation, it represents a significant stability issue and potential denial of service vector. The repeated unpinning corrupts internal reference counts used by the driver to track resource usage, potentially leading to use-after-free scenarios if other parts of the kernel assume the buffer is still pinned based on stale state information.

From a vulnerability classification perspective, this defect aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it involves incorrect handling of shared hardware resources and their lifecycle states. It also relates to CWE-401: Missing Release of Memory after Effective Lifetime if the underflow leads to resource leaks that degrade system performance over time, or more accurately CWE-823: Use of Out-of-range Pointer Offset in terms of memory management logic errors. In the context of the MITRE ATT&CK framework for Linux systems, this falls under T1496: Resource Hijacking, as improper resource management can lead to degraded system availability and performance due to corrupted driver state or excessive warning logs consuming CPU cycles during process termination.

The remediation involves restructuring the control flow within amdgpu_amdkfd_gpuvm_free_memory_of_gpu to ensure that ttm_bo_unpin is only executed after confirming that the buffer object is no longer mapped to GPU memory and that it is safe to proceed with deallocation. By moving the unpin operation to occur strictly when the driver is committed to freeing the buffer, the code prevents double-unpinning events. This fix ensures that the pin count remains consistent throughout the lifecycle of the buffer object, maintaining the integrity of the TTM subsystem's memory management logic and preventing the generation of kernel warnings or potential instability during high-load scenarios involving frequent GPU context creation and destruction by user-space applications.

Responsible

Linux

Reservation

08/26/2026

Disclosure

08/28/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!