CVE-2025-38011 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]
Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm]
drm_close_helper.isra.0+0x65/0x70 [drm]
drm_release+0x6a/0x120 [drm]
amdgpu_drm_release+0x51/0x60 [amdgpu]
__fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0
(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/02/2026
The vulnerability identified as CVE-2025-38011 affects the Linux kernel's AMDGPU display driver component, specifically within the direct rendering manager subsystem. This issue manifests during the process cleanup phase when a graphics application terminates and the kernel attempts to unmap constant shader area (CSA) memory regions and free associated GPU virtual memory. The flaw occurs in the context of DRM (Direct Rendering Manager) file handling where the kernel must properly manage GPU resources during process exit operations. The vulnerability stems from improper locking mechanisms that fail to handle interruptions during critical memory management operations, leading to potential memory leaks and system instability.
The technical root cause involves the use of interruptible wait locks during GPU virtual memory management operations. When a process exits and the kernel attempts to clean up GPU resources, the system must acquire a virtual memory lock to safely unmap memory regions and free constant shader areas. However, if a signal is delivered to the process during this cleanup phase, the interruptible lock mechanism allows the operation to be interrupted, causing the memory management routine to return prematurely without completing the necessary cleanup tasks. This results in memory leaks where GPU virtual memory pages remain allocated but unreferenced, creating potential denial of service conditions and resource exhaustion scenarios. The specific location of the issue is within the amdgpu_driver_postclose_kms function at line 1525 of the amd/amdgpu/amdgpu_kms.c source file.
The operational impact of this vulnerability extends beyond simple memory leaks to potentially compromise system stability and resource availability. When the interruptible lock mechanism fails during GPU memory cleanup, the system may experience gradual memory consumption increases as leaked GPU virtual memory accumulates over time. This can lead to performance degradation and eventually system instability when GPU memory resources become exhausted. The warning backtrace indicates that the issue occurs during normal process termination sequences, making it particularly concerning as it affects routine system operations rather than exceptional conditions. Attackers could potentially exploit this vulnerability to cause resource exhaustion through repeated process creation and termination cycles, leading to denial of service conditions that affect graphics rendering capabilities and overall system responsiveness.
The fix implemented addresses this vulnerability by changing the locking mechanism from interruptible to uninterruptible wait locks during the GPU virtual memory cleanup process. This modification ensures that when the kernel attempts to unmap CSA memory regions and free GPU virtual memory during process exit, the operation cannot be interrupted by incoming signals. The change prevents premature returns from the memory management routines and guarantees that all necessary cleanup tasks are completed before the process termination sequence continues. This approach aligns with the principle of maintaining system integrity during critical resource management operations and follows established security practices for preventing race conditions and resource leaks in kernel space. The fix has been cherry-picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab, indicating it follows established kernel development practices and has undergone appropriate review processes.
This vulnerability classification aligns with CWE-401: Improper Release of Memory Before Removing Last Reference and CWE-691: Insufficient Control Flow Management, as it involves both memory management issues and improper handling of control flow during system cleanup operations. The ATT&CK framework would categorize this under T1499.004: Endpoint Denial of Service, as it can lead to resource exhaustion and system instability through improper memory management. The vulnerability demonstrates the critical importance of proper locking mechanisms in kernel space operations, particularly when dealing with shared resources like GPU memory that must be carefully managed during concurrent access scenarios. The fix represents a standard security practice of using uninterruptible operations for critical resource management tasks, ensuring that system integrity is maintained even when signals are delivered to processes during cleanup operations.