CVE-2026-74721 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/amxdna: Fix page-insertion errors in amdxdna_insert_pages()
Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma) before returning an error code to the caller. This is incorrect: amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo that registration. Calling vm_ops->close() manually — which drops the shmem pages_pin_count and the GEM object reference that backs the VMA — before the mmap syscall has even returned causes those resources to be released while the VMA is still alive. The kernel VMA teardown will call vm_ops->close() a second time when the process later unmaps the range, producing a reference count underflow.
Replace both hard-error returns with a deferred-fault approach that keeps the VMA alive and retries page insertion through the HMM range-fault path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's AMD XDNA accelerator driver involves a critical resource management error within the amdxdna_insert_pages function, specifically affecting how virtual memory area resources are handled during fault resolution. The core technical flaw lies in two distinct error paths where the code incorrectly invokes vma->vm_ops->close on a hard failure before returning an error to the caller. This sequence of operations is fundamentally flawed because it disrupts the expected lifecycle management of kernel objects associated with user-space memory mappings. When amdxdna_gem_obj_mmap registers an Heterogeneous Memory Management interval notifier prior to calling this insertion routine, it establishes a dependency chain that expects specific cleanup procedures to occur only under controlled conditions. By manually triggering vm_ops->close during an error state, the driver prematurely drops shared memory page pin counts and releases the Graphics Execution Manager object reference backing the virtual memory area while the mapping remains active in user space.
This premature release of resources creates a dangerous race condition leading to a use-after-free scenario or reference count underflow. Since the VMA is still considered alive by the kernel's memory management subsystem, it will eventually undergo teardown when the process unmaps the range. During this standard cleanup phase, the kernel calls vm_ops->close again. Because the resources were already released during the earlier erroneous error path handling, this second invocation attempts to decrement reference counts that have reached zero or negative values. This underflow can lead to memory corruption, system instability, or potentially allow an attacker with local access to exploit these corrupted state variables for privilege escalation or denial of service conditions. The issue highlights a failure in adhering to proper kernel API usage patterns where error handling must not interfere with the ongoing lifecycle of active virtual memory structures.
From a security taxonomy perspective, this vulnerability aligns closely with CWE-416, Use After Free, as it involves accessing resources that have been prematurely deallocated due to incorrect control flow during error recovery. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, given the potential for race conditions between the manual cleanup and subsequent kernel teardown processes. In terms of MITRE ATT&CK mapping, this type of vulnerability is often leveraged in Local Privilege Escalation techniques where attackers manipulate memory management subsystems to gain unauthorized access or disrupt system integrity by exploiting improper resource tracking within device drivers. The impact extends beyond simple crashes; it compromises the isolation guarantees provided by the kernel's virtual memory manager, potentially allowing malicious actors to read or write arbitrary kernel memory if they can trigger these specific error paths repeatedly.
The resolution involves replacing the immediate hard-error returns with a deferred-fault approach that preserves the integrity of the VMA and its associated resources until proper cleanup is warranted. By deferring fault handling through the HMM range-fault path, the driver ensures that page insertion retries occur in a context where reference counts are correctly maintained and lifecycle events are synchronized properly. This architectural change prevents the premature release of shmem pages and GEM object references, thereby eliminating the possibility of double-free or underflow scenarios during VMA teardown. To mitigate similar issues in other drivers, developers should ensure that error paths do not invoke cleanup functions like vm_ops->close unless explicitly required by the memory management subsystem's contract for that specific operation state. Regular auditing of driver code against kernel documentation regarding mmap and fault handling semantics is essential to prevent such resource management errors from reaching production kernels.