Linux Kernel CVE-2026-89808

Requires local access to an AMD GPU exposing the KFD compute interface and the ability to drive SVM (Shared Virtual Memory) HMM migrations to VRAM - i.e. a ROCm/HSA-capable AMD GPU with the amdkfd driver in use. Exploitation is further gated on hitting the specific error condition: a migration VM range that is a CPU-side hole (MIGRATE_PFN_MIGRATE set, MIGRATE_PFN_VALID unset) such that no source pages are DMA-mapped and no copy occurs (j==0), causing the uninitialized return value to be used. Limiting factors: local-only (no network vector), requires an unprivileged-but-present GPU device handle, depends on a non-default/racy memory layout condition and on stack garbage being non-zero, making reliable triggering non-trivial. Not exploitable against systems without AMD KFD/SVM in use.

The vendor CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk for what the description reveals to be an error-handling/reliability defect in the AMD KFD SVM migration path (svm_migrate_copy_to_vram). The flaw is an uninitialized return variable r that is returned when a migration VM range is a CPU-side hole (MIGRATE_PFN_MIGRATE set but MIGRATE_PFN_VALID unset) and no pages are actually copied (j==0); a non-zero garbage value then drives the out_free_vram_pages cleanup path to drop all VRAM that was just set up. This is a local-only vulnerability requiring the ability to drive GPU SVM/HMM migration, i.e. an unprivileged local user with access to an AMD KFD compute device - consistent with AV:L/PR:L. However, AC:L is optimistic: triggering the bug requires a specific and racy condition (a hole appearing in the migration range mid-operation) plus reliance on stack garbage in r, so realistic exploitation complexity is higher (AC:H/AT:P). There is no KEV listing, no known public exploit, and no EPSS score provided, so all signals point to a theoretical/latent defect rather than an exploited priority. The 'C:H/I:H/A:H' triad is not well justified by the text - the concrete observable effect is erroneous freeing/loss of just-configured VRAM (integrity/availability of GPU memory state), not a demonstrated confidentiality leak.

An unprivileged local user with access to an AMD KFD compute device (ROCm/HSA workload) issues SVM memory migrations to VRAM and arranges for a migration range to contain a CPU-side hole so that no source pages are DMA-mapped or copied. The uninitialized return value then triggers the cleanup path that drops all VRAM pages that were just allocated and set up, corrupting or destabilizing GPU memory state. No public exploit code has been identified at time of analysis, and success depends on hitting the specific hole/no-copy condition.