CVE-2026-89804 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dmem: fix mismatched DMA unmap size for large folios
Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page():
- nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path.
For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's DRM Nouveau driver contains a resource management flaw within its device-private transparent huge page migration logic that results in IOMMU mapping leaks. This vulnerability arises from an inconsistency between how memory mappings are established and how they are subsequently released during the lifecycle of large folios, specifically those representing compound pages with orders greater than zero. The core issue lies in the mismatched DMA unmap size when handling these larger memory structures, leading to persistent allocations that consume system resources without being properly reclaimed by the kernel's memory management subsystems.
The technical root cause is located in two specific teardown paths within the nouveau_dmem module: nouveau_dmem_migrate_to_ram() on the success path and nouveau_dmem_migrate_copy_one() on the copy-error path. During the initial mapping phase, migration buffers are mapped using page_size(), which correctly calculates the total size for a compound folio as PAGE_SIZE multiplied by two raised to the order of the folio. This calculated length is stored in dma_info->size and should be used during unmapping operations. However, both affected functions incorrectly pass a literal PAGE_SIZE value to the dma_unmap_page() function instead of utilizing the saved size from dma_info->size. For standard single-page allocations where the order is zero, this error has no practical impact because PAGE_SIZE equals page_size(). The vulnerability only manifests when dealing with large folios where the order exceeds zero, causing the unmap operation to release only a fraction of the originally allocated IOMMU or IOVA mapping space.
This mismatch results in a progressive leak of IOMMU and IOVA mappings every time such a migration occurs successfully or encounters an error during copying. Because the remainder of the mapping is not unmapped, it remains reserved by the hardware translation layer even though the underlying memory pages may have been freed or repurposed. Over time, this accumulation of unreleased mappings can exhaust the available IOMMU address space or IOVA ranges, particularly on systems with limited DMA addressing capabilities or those running workloads that frequently trigger large folio migrations. Such exhaustion can lead to allocation failures for subsequent device operations, potentially causing driver instability, performance degradation due to fallback mechanisms, or in severe cases, a denial of service condition where the graphics subsystem becomes unresponsive until a system reboot clears the stale mappings.
From a classification perspective, this vulnerability aligns with CWE-401, which describes a missing release of memory after effective usage, specifically manifesting here as an IOMMU mapping leak rather than traditional host RAM leakage. It also relates to CWE-756, Missing Explanation of Special Case Behavior, as the code failed to account for the different size requirements of compound pages compared to standard pages in its cleanup routines. In terms of attack surface and behavior, this flaw does not directly enable privilege escalation or remote code execution but represents a resource exhaustion vector that could be leveraged by local users with access to GPU-accelerated workloads to degrade system stability through sustained allocation pressure on the IOMMU subsystem.
The mitigation for this issue involves correcting the DMA unmap calls in the affected functions to use the size value recorded during mapping rather than assuming a single page size. By ensuring that nouveau_dmem_migrate_to_ram() and nouveau_dmem_migrate_copy_one() pass dma_info->size to dma_unmap_page(), the driver will correctly release all allocated IOMMU entries corresponding to the mapped folio. This change aligns these paths with other teardown sites in the module, such as nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), which already utilize the saved size for proper cleanup. System administrators should apply kernel updates that include this patch to prevent resource leaks during GPU memory migration operations, thereby maintaining system stability and preventing potential denial of service conditions caused by IOMMU address space exhaustion.