drm/pagemap: migration error path clears the pages array before DMA-unmapping it

CVSS 8.8CVE-2026-93284NVIDIA / GPU stackcurated

Impact

drm_pagemap_migrate_unmap_pages() reads the pages array to decide which pages still need DMA unmapping, but on the error path drm_pagemap_migration_unlock_put_pages() runs first and clears that array, so the unmap sees no valid page information and DMA mappings are left behind. The fix reorders the two calls. This is in the DRM pagemap code that backs device-memory migration for GPU SVM/HMM - the path a compute workload exercises when pages move between system and device memory - so it is reachable by a local user with a GPU context whenever migration fails. The kernel record does not spell out the consequence beyond the leaked/incorrectly-handled mapping; treat it as local corruption or leaked IOMMU mappings on the GPU node rather than an established privilege-escalation primitive. The 8.8 local score is the kernel CNA's automated rating, not a demonstrated escalation.

Who can reach it

Local user with an open GPU device context on the node - in practice any tenant with a GPU pod or VM on hardware whose driver uses drm_pagemap-backed SVM migration. No remote path.

What to do

Take the stable-kernel fix (two stable branches carry it) and reboot the affected GPU nodes; DRM core cannot be swapped under a running workload. Schedule it with your regular driver/kernel maintenance rather than as an emergency window unless you have evidence of the error path being hit.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-93284 https://git.kernel.org/stable/c/9e6372ec2a3990662ae0a67f56ac0aee19848d5b https://git.kernel.org/stable/c/e4331c6644db85bc6ceb470bd84bcf371b6dbfa6

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.