CVE-2026-89804: drm/nouveau/dmem: fix mismatched DMA unmap size for large folios
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 pagesize() and records that length in dmainfo->size. For a compound folio pagesize() is PAGESIZE << order, but two teardown sites still pass a literal PAGESIZE to dmaunmappage():
- nouveaudmemmigratetoram() on the success path, and - nouveaudmemmigratecopyone() 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 nouveaudmemmigratechunk() and nouveaudmemevictchunk(), already use the saved size; use it here too.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's nouveau DRM driver with device-private memory migration are exposed when large compound folios are migrated. The mismatch occurs only for folios with an order greater than 0; base-page mappings use the same size as PAGE_SIZE.
What happens when the vulnerable paths are reached?
On a successful migration back to RAM or a copy-error path, the driver unmaps only PAGE_SIZE even though the migration buffer was mapped at the larger folio size. This can leave the remaining IOMMU/IOVA mapping allocated.
How can I determine whether a system has the fix?
Check whether the kernel's nouveau dmem code passes the saved dma_info->size value, rather than a literal PAGE_SIZE, to dma_unmap_page() in nouveau_dmem_migrate_to_ram() and nouveau_dmem_migrate_copy_one(). The referenced stable commits contain the resolution.