In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix error path at svm_migrate_copy_to_ram
If page migration from device to sys ram fails for some reasons driver needs
release and unlock allocated system pages. To do that driver should use page
physical address, or pfn, then get struct page*. Current driver uses dma
address(for adev) that is not correct with IOMMU enabled, or even in general.
The patch releases and unlocks allocated system pages based on where migration
failed by struct page* of sys ram pages. Also dma_unmap correspodent system
ram pages at error path.
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 in amdkfd SVM VRAM-to-RAM migration (svm_migrate_copy_to_ram), reached from local /dev/kfd AMDKFD_IOC_SVM ioctls, CPU/GPU page faults, or TTM eviction in the caller’s process; it is not reachable from the network stack.
AC:L - An attacker who can open /dev/kfd fully controls SVM prefetch and faults and can force the failing copy path (alloc_page_vma ENOMEM, dma_map_page failure, or GART IB allocation failure) via memory or DMA-mapping pressure; no uncontrollable race or rare config is required.
PR:L - kfd_open() and AMDKFD_IOC_SVM perform no capability check; /dev/kfd and the amdgpu render node are accessible to unprivileged users in the render group, which is standard on AMD GPU, ROCm, HPC, and embedded systems.
UI:N - The attacker opens /dev/kfd, establishes an SVM range, and triggers VRAM-to-RAM migration from their own process; no other user must mount, open, or interact with anything.
S:U - Impact is kernel page-refcount and vmemmap corruption inside the host kernel that runs amdkfd. This is standard local kernel memory corruption, not a guest-to-host escape or IOMMU DMA-isolation bypass.
C:H - On the error path the driver treats DMA addresses (IOMMU IOVAs, bounce-buffer addresses, or 0 for skipped pages) as PFNs and put_page()s the resulting struct page, a use-after-free/refcount underflow of unrelated pages that can disclose kernel memory.
I:H - The same wrong-page unlock_page()+put_page() can free still-mapped pages or drop the lock on pages other code holds, and invalid PFNs write through pfn_to_page() into vmemmap; that is an exploitable write/UAF primitive for control-flow hijack.
A:H - pfn_to_page() without pfn_valid() on a DMA IOVA, unlock_page() of an unlocked page, and later use of an underflowed page refcount each produce a kernel oops or panic, fully denying availability.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is in amdkfd SVM VRAM-to-RAM migration (svm_migrate_copy_to_ram), reached from local /dev/kfd AMDKFD_IOC_SVM ioctls, CPU/GPU page faults, or TTM eviction in the caller’s process; it is not reachable from the network stack.
AC:L - An attacker who can open /dev/kfd fully controls SVM prefetch and faults and can force the failing copy path (alloc_page_vma ENOMEM, dma_map_page failure, or GART IB allocation failure) via memory or DMA-mapping pressure; no uncontrollable race or rare config is required.
PR:L - kfd_open() and AMDKFD_IOC_SVM perform no capability check; /dev/kfd and the amdgpu render node are accessible to unprivileged users in the render group, which is standard on AMD GPU, ROCm, HPC, and embedded systems.
UI:N - The attacker opens /dev/kfd, establishes an SVM range, and triggers VRAM-to-RAM migration from their own process; no other user must mount, open, or interact with anything.
S:U - Impact is kernel page-refcount and vmemmap corruption inside the host kernel that runs amdkfd. This is standard local kernel memory corruption, not a guest-to-host escape or IOMMU DMA-isolation bypass.
C:H - On the error path the driver treats DMA addresses (IOMMU IOVAs, bounce-buffer addresses, or 0 for skipped pages) as PFNs and put_page()s the resulting struct page, a use-after-free/refcount underflow of unrelated pages that can disclose kernel memory.
I:H - The same wrong-page unlock_page()+put_page() can free still-mapped pages or drop the lock on pages other code holds, and invalid PFNs write through pfn_to_page() into vmemmap; that is an exploitable write/UAF primitive for control-flow hijack.
A:H - pfn_to_page() without pfn_valid() on a DMA IOVA, unlock_page() of an unlocked page, and later use of an underflowed page refcount each produce a kernel oops or panic, fully denying availability.
CVSS 3.1