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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
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.