CVE-2026-89808 in Linux
Summary
by MITRE • 09/16/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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's DRM AMD KFD subsystem involves a critical logic error within the SVM (Shared Virtual Memory) migration path, specifically during the operation of copying data to VRAM via the function svm_migrate_copy_to_vram. This issue arises when the virtual memory range on the CPU side is classified as a hole, indicated by specific page frame number flags where MIGRATE_PFN_MIGRATE is set but MIGRATE_PFN_VALID is unset. In this scenario, the driver incorrectly proceeds to allocate device pages despite the absence of valid source data or DMA mappings for those pages. This misalignment between state expectation and actual resource availability creates a dangerous condition that can lead to memory corruption or system instability.
The technical flaw manifests when the migration loop processes these invalid ranges. Because there are no valid source pages, the variable j remains at zero, which causes the function svm_migrate_copy_memory_gart to return an uninitialized value for r. This uninitialized return value is then passed into subsequent cleanup routines, specifically triggering out_free_vram_pages. Consequently, this routine erroneously drops all VRAM memory that was just set up during the migration process. The result is a loss of allocated video RAM resources without proper data transfer or state management, potentially leading to graphical artifacts, application crashes, or kernel panics depending on the context in which the allocation occurs.
From an operational impact perspective, this vulnerability allows for local denial-of-service conditions and potential information disclosure if the uninitialized memory contains sensitive data that is inadvertently exposed through improper cleanup paths. The flaw resides in the error handling and loop termination logic of the migration subsystem. By failing to validate whether any actual pages were successfully processed before attempting final copy operations or resource release, the code violates basic principles of safe state transition. This can be exploited by local users who have access to GPU resources via AMD KFD interfaces, potentially disrupting other processes sharing the same graphics hardware context.
The remediation involves initializing the variable r and ensuring that svm_migrate_copy_memory_gart is only invoked when j is greater than zero, confirming that actual pages were migrated. Additionally, the patch modifies the loop logic to flush on the last page upon reaching the end of the current drm_buddy_block, thereby avoiding redundant or erroneous calls to migration functions. This change ensures that resources are managed correctly and prevents the release of VRAM when no valid data transfer occurred.
This vulnerability aligns with CWE-457, which describes the use of an uninitialized variable, as well as CWE-209, regarding the generation of error messages containing sensitive information if the uninitialized memory leaks into logs or debug outputs. In terms of MITRE ATT&CK mapping, this flaw relates to T1059 Command and Scripting Interpreter execution contexts where local privilege escalation might be attempted through resource exhaustion or state manipulation within kernel space. Security practitioners should ensure that systems running affected versions of the Linux kernel are updated with patches addressing drm/amdkfd migration logic errors. Administrators monitoring for unusual GPU driver behavior or unexpected VRAM allocation failures in logs may find indicators consistent with this vulnerability being triggered under heavy SVM workloads.