CVE-2026-89808 PUBLISHED

drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram

Assigner: Linux
Reserved: 11.09.2026 Published: 16.09.2026 Updated: 16.09.2026

In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram

When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up.

Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0.

Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart.

Metrics

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8

AV:L - The bug is reached only via local /dev/kfd AMDKFD_IOC_SVM (SET_ATTR prefetch) or the process's own GPU page-fault SVM restore into svm_migrate_copy_to_vram; it is not reachable from network packets, adjacent wireless, or a physical bus. AC:L - An attacker creates anonymous VMA holes (untouched mmap or zero pages) and triggers migration with AMDKFD_IOC_SVM PREFETCH_LOC; migrate_vma records MIGRATE_PFN_MIGRATE without VALID so j stays 0 and the uninitialized-r path runs with no race, victim state, or rare config (HSA_AMD_SVM defaults y). PR:L - kfd_open() and AMDKFD_IOC_SVM perform no capable() checks (ioctl flag 0, unlike CRIU); /dev/kfd and the DRM render node are available to unprivileged render-group users on typical ROCm, desktop, and Android AMD GPU systems, which is Low privilege not init-namespace root. UI:N - Exploitation uses only the attacker's own /dev/kfd file descriptor, anonymous mappings, and SVM ioctls; no separate victim must mount a filesystem, open a file, or take any other action. S:U - Impact is confined to amdkfd SVM/GPUVM state and ZONE_DEVICE pages in the host kernel; it does not cross a VM, hypervisor, IOMMU device-isolation, or sandbox security authority. C:H - Spurious out_free_vram_pages unlocks and puts destination ZONE_DEVICE pages (page_free → svm_range_bo_unref_async) while SDMA may still copy into that VRAM and a non-zero leftover r can still mark the range GPU-resident; that device-page UAF enables kernel/VRAM disclosure. I:H - The same premature free of migrate destination pages, while actual_loc/vram_pages may still record a successful GPU migration, lets later HMM/GPUVM/SDMA operate on put ZONE_DEVICE pages and svm_bo refs, a kernel UAF write/control-flow primitive scored High per UAF guidance. A:H - Putting still-in-use ZONE_DEVICE pages and leaving SVM actual_loc/vram_pages inconsistent reliably causes kernel oops/WARN (bad page lock, folio_put on freed pages, VRAM BO validation) or GPU hang/reset, which is High availability impact.

Product Status

Vendor Linux
Product Linux
Versions Default: unaffected
  • affected from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to ae806a95b28fcecb913430cfa45a252e91a945d6 (excl.)
  • affected from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to 0a9a0e8a97da70a0336c9115178aaf1be29bcfb1 (excl.)
  • affected from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to 520e345ffe05aabef1db82beda4288afb1757ff2 (excl.)
  • affected from 0 to 6.18.51 (excl.)
  • affected from 0 to 7.2.5 (excl.)
Vendor Linux
Product Linux
Versions Default: affected
  • unaffected from 6.18.51 to 6.18.* (incl.)
  • unaffected from 7.2.5 to 7.2.* (incl.)
  • unaffected from 7.3-rc1 to * (incl.)

References