drm_pagemap: use-after-put in the device-to-RAM migration error path, plus missing THP fallback

Impact

When migrating GPU device memory back to system RAM, the error path computed the folio order via page_folio(page) after put_page() had already dropped the last reference - a use-after-free on the page struct. The same function had no fallback when a higher-order (THP) folio allocation failed, so under memory pressure it both spammed the log and left part of the range uncopied. drm_pagemap is the shared migration layer behind device SVM on Xe and AMD GPUs, so this sits directly in the path that unified-memory workloads exercise constantly. On a GPU node the trigger is ordinary memory pressure during eviction, which is exactly the state a busy multi-tenant box is in; the realistic outcome is host memory corruption or silently wrong data after a failed migration.

Who can reach it

Local. Any tenant running an SVM/unified-memory GPU workload that forces eviction of device pages back to RAM under memory pressure. No authentication beyond holding a render node fd; the error path is reached by allocation failure rather than by a crafted input.

What to do

Install the stable-kernel update that computes the folio order before releasing the page and adds the order-0 fallback with per-page source population. This is an in-tree DRM change, so it requires the patched kernel: drain the node and reboot. No vendor userspace or daemon restart addresses it, and there is no configuration mitigation short of not using device SVM.

References

Related entries

• amdkfd: uninitialized return on a hole in the migrated range drops VRAM pages just allocatedCVE-2026-89808 · Linux kernel amdkfd (svm_migrate_copy_to_vram, hole in the migration VM range)High
• amdkfd: device-to-RAM migration error path releases pages by DMA address, corrupting unrelated pagesCVE-2026-89810 · Linux kernel amdkfd (svm_migrate_copy_to_ram error path, DMA address used as PFN)High
• amdgpu: rings outside a partition index the isolation array out of bounds on SDMA submitCVE-2026-89814 · Linux kernel amdgpu (adev->isolation[] indexed with AMDGPU_XCP_NO_PARTITION)High
• drm/ttm: stale restore state after a successful restore leaves shmem handles in the page arrayCVE-2026-89815 · Linux kernel drm/ttm (ttm_pool_restore_and_alloc, stale tt->restore)High
• Linux kernel drm/xe: flat CCS storage published as usable VRAM, corrupting allocationsCVE-2026-90047 · Linux kernel drm/xe (flat CCS offset rounding)High
• NVIDIA GPU Display Driver - kernel mode layer (Windows nvlddmkm.sys and Linux nvidia.ko): An out-of-bounds readCVE-2022-28183 · NVIDIA GPU Display Driver - kernel mode layer (Windows nvlddmkm.sys and Linux nvidia.ko)High