Look up another CVE · open CVE-2026-72449 in the interactive tracker
CVE-2026-72449
drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm
Published 2026-08-15 (2 months 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-72449 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The cleanup tail of kfd_criu_resume_svm() walks svms->criu_svm_metadata_list and kfree()s each struct criu_svm_metadata without removing it from the list. The list head is left pointing at freed kmalloc-96 objects. A second AMDKFD_IOC_CRIU_OP from the same process re-enters: list_empty() reads the dangling ->next (use-after-free), the loop walks freed entries, and each is kfree()'d again (double-free). This is reachable by an unprivileged render-group user via /dev/kfd with no capabilities required. Add list_del() before the kfree() so the list is properly emptied. The list_for_each_entry_safe() iterator already caches the next pointer, so unlinking during the walk is safe. (cherry picked from commit 6322d278a298e2c1430b9d2697743d3a04b788b1)
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_svm.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-08-15 (2 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.17%, higher than 6.1% 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.18 | 6.1.178 | c8a8d350a273 |
| 5.18 | 6.6.145 | 506e635aed05 |
| 5.18 | 6.12.97 | 838b57b3e7ce |
| 5.18 | 6.18.40 | 96ac562a9ea3 |
| 5.18 | 7.1.5 | e33a3bd5cb8d |
| 5.18 | 7.2 | 8fa5655da368 |
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 via the local AMDKFD_IOC_CRIU_OP ioctl on /dev/kfd (unlocked_ioctl -> kfd_ioctl_criu -> criu_resume -> kfd_criu_resume_svm); there is no network, adjacent-radio, or physical-device entry path.
- AC:LAttack complexity, low
- An attacker who can open /dev/kfd controls the full CRIU restore/resume ioctl sequence and can deterministically trigger the bug by issuing KFD_CRIU_OP_RESUME twice after restore populates criu_svm_metadata_list; no uncontrollable race or rare layout is required.
- PR:LPrivileges required, low
- The fix commit and ioctl path show exploitation by a local render-group user opening /dev/kfd; CAP_CHECKPOINT_RESTORE/SYS_ADMIN gates CRIU ioctls but are obtainable in a user namespace, matching basic local user privilege rather than init-namespace root only.
- UI:NUser interaction, none
- Exploitation requires only the attacker's own ioctl calls to /dev/kfd after CRIU restore; no victim click, mount, file open, or other interactive action is needed.
- S:UScope, unchanged
- Corruption is confined to kernel heap list metadata in amdkfd for the calling KFD process context; impact stays within the kernel security authority and does not cross a VM, IOMMU, or hypervisor boundary.
- C:HConfidentiality impact, high
- After the first resume, list_empty() and list iteration dereference freed kmalloc-96 criu_svm_metadata objects (use-after-free reads of ->next/list pointers), enabling attacker-influenced heap disclosure beyond a bounded leak.
- I:HIntegrity impact, high
- A second resume walks the corrupted list and kfree()s the same objects again (double-free on kmalloc-96 slabs), a standard exploitable kernel heap primitive for arbitrary memory corruption and potential privilege escalation.
- A:HAvailability impact, high
- The use-after-free and double-free reliably corrupt kernel heap state and commonly cause BUG/KASAN faults, oops, or panic when the dangling list is traversed again, producing system-wide denial of service.