Look up another CVE · open CVE-2026-63879 in the interactive tracker
CVE-2026-63879
drm/amdgpu: fix amdgpu_hmm_range_get_pages
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/gpu. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63879 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| 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.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The notifier sequence must only be read once or otherwise we could work with invalid pages. While at it also fix the coding style, e.g. drop the pre-initialized return value and use the common define for 2G range. (cherry picked from commit c08972f555945cda57b0adb72272a37910153390)
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/amdgpu/amdgpu_hmm.c
- What this is
- RADEON and AMDGPU DRM DRIVERSMAINTAINERS section matched on drivers/gpu/drm/amd/ · amd-gfx@lists.freedesktop.org · Supported
- Kernel module
- amdgpu
Check it on the machine
grep -wE 'CONFIG_DRM_AMDGPU|CONFIG_HMM_MIRROR' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w amdgpuPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- M
- a module where it is built at all; some flavours do not build it
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.
- Build switches
- CONFIG_DRM_AMDGPU, CONFIG_HMM_MIRROR
- Reads as
- all on means the file is compiled; any one off means it is not.
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 kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months 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.18%, higher than 7.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.2 | 6.18.57 | fa34d3e14cb7 |
| 6.2 | 7.0.12 | 2fd24407457a |
| 6.2 | 7.1 | 962d684b5dc0 |
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 reached only through local AMDGPU DRM ioctls (e.g., AMDGPU_GEM_USERPTR, AMDGPU_CS) and KFD ioctls on /dev/kfd that call amdgpu_hmm_range_get_pages(); there is no network-facing entry point.
- AC:LAttack complexity, low
- Exploitation requires a >2GB userptr/SVM mapping and a concurrent munmap/remap during the multi-chunk HMM walk, but the attacker controls both the ioctl thread and the address-space manipulation, so the race is attacker-driven rather than dependent on uncontrollable conditions.
- PR:LPrivileges required, low
- Any unprivileged local user with access to the AMDGPU render node or /dev/kfd (typically render/video group membership) can create large userptr buffers and submit GPU work that triggers the vulnerable HMM path; root or init-namespace capabilities are not required.
- UI:NUser interaction, none
- Exploitation is fully attacker-driven through GPU memory registration and command submission ioctls and does not require any action from another user or administrator.
- S:UScope, unchanged
- The flaw corrupts or misuses kernel-tracked page metadata and enables standard local kernel memory safety impact and privilege escalation within the same kernel security domain, not a VM escape or IOMMU boundary bypass.
- C:HConfidentiality impact, high
- Re-reading the MMU notifier sequence per 2GB chunk lets later validation pass while earlier PFNs may reference unmapped or freed pages, giving the GPU (and kernel DMA helpers) a stale-page/use-after-free primitive that can disclose arbitrary physical memory contents.
- I:HIntegrity impact, high
- Stale PFNs from invalidated mappings can be DMA-mapped and written by GPU operations, enabling arbitrary memory corruption and potential control-flow hijacking via repurposed physical pages rather than a bounded or crash-only effect.
- A:HAvailability impact, high
- Operating on invalid struct page pointers during pinning/DMA mapping can trigger kernel oopses or panics, and the underlying use-after-free class of bug inherently threatens system availability even when full exploitation is not attempted.