Look up another CVE · open CVE-2026-89810 in the interactive tracker
CVE-2026-89810
drm/amdkfd: Fix error path at svm_migrate_copy_to_ram
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89810 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
- What this is
- AMD KFDMAINTAINERS section matched on drivers/gpu/drm/amd/amdkfd/ · amd-gfx@lists.freedesktop.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/gpu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.14 | 6.18.51 | da87bcad1f78 |
| 5.14 | 7.2.5 | a2035918a7a1 |
| 5.14 | 7.3 | 960c4a8069bf |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- 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:LAttack complexity, low
- 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:LPrivileges required, low
- 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:NUser interaction, none
- 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:UScope, unchanged
- 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:HConfidentiality impact, high
- 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:HIntegrity impact, high
- 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:HAvailability impact, high
- 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.