amdkfd: device-to-RAM migration error path releases pages by DMA address, corrupting unrelated pages

CVSS 7.8CVE-2026-89810NVIDIA / GPU stackcurated

Impact

When migration from VRAM back to system RAM fails, the driver has to release and unlock the system pages it allocated. It derived struct page from the device DMA address instead of the physical address, which is simply wrong with an IOMMU in play - and datacenter AMD nodes run with the IOMMU on. The error path therefore unlocked and put page structs belonging to unrelated memory, and left the real pages DMA-mapped and locked. This is a distinct bug from the VRAM-side migration fix in the same series: it lives in the copy-to-RAM direction and its damage lands on host memory outside the tenant's allocation. On a shared ROCm node a tenant who can make a migration fail can corrupt refcounts on pages another workload owns.

Who can reach it

Local. Any tenant holding /dev/kfd that can drive an SVM migration back to system RAM into a failure (memory pressure, DMA mapping failure). No special privilege required.

What to do

Take the stable-kernel update that walks the system-RAM struct pages directly and dma_unmaps them on the error path. Kernel-tree fix: drain the node's GPU workloads and reboot into the patched kernel, or rebuild and reload the packaged AMD kernel module with the GPUs idle. No runtime mitigation short of disabling SVM migration for untrusted workloads.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89810 https://git.kernel.org/stable/c/960c4a8069bfd352c48cc88592618f1ebe24c69e https://git.kernel.org/stable/c/a2035918a7a1d8fd3bb79d22e1e149294a5a8418 https://git.kernel.org/stable/c/da87bcad1f781d822e7ced6d1de9dbc6d381c72e

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.