CVE-2026-72093 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()
When vm_insert_pages() fails, the error path calls vma->vm_ops->close(vma) which internally calls drm_gem_vm_close() → drm_gem_object_put(), releasing the GEM object reference acquired at the start of the function. However, the close_vma label then falls through to put_obj, which calls drm_gem_object_put() a second time on the same object.
If the first put releases the last reference, the object is freed and the second put accesses freed memory, causing a use-after-free.
Fix by returning directly from close_vma instead of falling through to put_obj, since the close handler already performs all necessary cleanup including the object put.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the AMD XDNA driver in the Linux kernel's graphics subsystem, specifically in the acceleration framework that handles GPU memory management operations. The issue manifests as a use-after-free condition that occurs during the memory mapping process for DMA buffers, representing a critical security flaw that could potentially be exploited to gain unauthorized access or cause system instability. The vulnerability stems from improper handling of reference counting within the graphics execution manager gem object lifecycle management.
The technical flaw occurs in the amdxdna_gem_dmabuf_mmap() function where vm_insert_pages() failure triggers an error path that incorrectly manages GEM object references. When vm_insert_pages() fails, the code invokes vma->vm_ops->close(vma) which internally calls drm_gem_vm_close() followed by drm_gem_object_put(), releasing the initial reference acquired at function start. However, execution then falls through to a close_vma label that subsequently calls drm_gem_object_put() again on the same object, creating the use-after-free scenario when the second put operation attempts to access memory that has already been freed.
This vulnerability directly relates to CWE-416, which addresses use-after-free conditions in software systems, and represents a classic double-free or use-after-free error pattern. The operational impact of this flaw extends beyond simple memory corruption as it could potentially allow attackers to execute arbitrary code with kernel privileges, particularly when the vulnerable driver is loaded and used in systems with GPU acceleration capabilities. The vulnerability affects Linux kernel versions that include the AMD XDNA driver implementation where graphics memory management operations are performed.
The fix implemented addresses the root cause by modifying the error handling flow to return directly from the close_vma label instead of falling through to the put_obj cleanup section. This prevents the double invocation of drm_gem_object_put() on the same GEM object, ensuring proper reference counting and preventing access to freed memory. The solution aligns with ATT&CK technique T1068 by addressing a kernel-level vulnerability that could be leveraged for privilege escalation, while also following secure coding practices recommended in the Linux kernel security guidelines.
Security implications of this vulnerability extend to systems running affected kernel versions where AMD XDNA GPU acceleration is utilized, particularly server environments or desktop systems with integrated graphics processing units. The flaw represents a serious concern for enterprise security teams as it could be exploited by malicious actors to gain elevated privileges within the kernel space, potentially compromising the entire system integrity. Organizations should prioritize applying the kernel patch that implements this fix to protect against potential exploitation attempts targeting this specific use-after-free condition in the AMD XDNA graphics driver implementation.
The vulnerability demonstrates how complex memory management operations in kernel drivers can introduce subtle but critical security flaws when reference counting mechanisms are not properly coordinated across different code paths. This particular case highlights the importance of careful error path handling in kernel modules, particularly those dealing with graphics memory management where multiple subsystems interact through shared object references. The fix serves as a reminder of the need for thorough testing of error conditions in kernel code and proper adherence to reference counting best practices.