Linux kernel nouveau/dmem: large-folio migration unmaps PAGE_SIZE instead of the mapped size, leaking IOVA

CVSS 8.8CVE-2026-89804NVIDIA / GPU stackcurated

Impact

Device-private THP migration maps migration buffers with page_size() and records that length, but nouveau_dmem_migrate_to_ram() on success and nouveau_dmem_migrate_copy_one() on the copy-error path still pass a literal PAGE_SIZE to dma_unmap_page(). For an order>0 folio less is unmapped than was mapped, so the remainder of the IOMMU/IOVA mapping stays live after the buffer is released - device-addressable memory that outlives its owner, plus IOVA-space exhaustion over time. The fix uses the saved size at both sites, matching the other unmap sites. Relevant only where nouveau is the NVIDIA driver in use; datacenter fleets on the proprietary or open NVIDIA kernel modules are not affected.

Who can reach it

Local user running GPU workloads that trigger device-private page migration on a host using the nouveau driver. No remote access; no special privilege beyond GPU access.

What to do

Update to a stable kernel carrying the two linked commits and reboot the affected hosts. Operators running the NVIDIA-supplied kernel modules rather than nouveau do not need to act. The record names commits, not fixed releases.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89804 https://git.kernel.org/stable/c/4deb29b9d33bfdb3de4d2d9944947ecf77221e42 https://git.kernel.org/stable/c/caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.