GPU VulnDB

Database/NVIDIA / GPU stack

amdkfd: uninitialized return on a hole in the migrated range drops VRAM pages just allocated

CVSS 7.8CVE-2026-89808NVIDIA / GPU stackcurated

Impact

svm_migrate_copy_to_vram() still allocated device pages when the CPU-side range was a hole (MIGRATE_PFN_MIGRATE set without MIGRATE_PFN_VALID). With nothing to map or copy, the copy helper returned an uninitialized value, which could send the function down out_free_vram_pages and free all of the VRAM it had just set up. For a ROCm node this is in the heart of the HSA shared-virtual-memory migration path used by every unified-memory kernel: a tenant whose address range happens to contain a hole can get device memory released out from under a live mapping, with the state of the queue's VRAM allocation decided by stack garbage. Expect memory corruption or GPU faults rather than a clean error, and a node whose GPU has to be reset to recover.

Who can reach it

Local. Any process holding /dev/kfd on an AMD GPU - i.e. any tenant with a ROCm container - that prefetches or migrates an SVM range containing an unmapped hole. No elevated privileges needed.

What to do

Apply the stable-kernel update that initializes r and only issues the final svm_migrate_copy_memory_gart() when j > 0. amdkfd is built into the kernel tree, so the fix ships with the kernel: drain the GPU jobs and reboot the node. If your fleet runs the packaged AMD DKMS stack instead, take the vendor kernel module build that carries the same commit and reload the driver with no GPU workloads attached.

References

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.