Look up another CVE · open CVE-2026-68104 in the interactive tracker
CVE-2026-68104
drm/amdgpu: invoke pm_genpd_remove() before freeing genpd
Published 2026-08-10 (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-68104 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 | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)
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_acp.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 -w CONFIG_DRM_AMDGPU /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.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- 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
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_DRM_AMDGPU
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-08-10 (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.13%, higher than 2.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 |
|---|---|---|
| 4.6 | 5.10.265 | 4d7c10b0bf09 |
| 4.6 | 5.15.216 | 493adf29d66f |
| 4.6 | 6.1.183 | 2e406b86144c |
| 4.6 | 6.6.148 | bdfc7f1e0900 |
| 4.6 | 6.12.101 | 5c0a82283271 |
| 4.6 | 6.18.42 | 08fee493e026 |
| 4.6 | 7.1.6 | 930a5dc3df4a |
| 4.6 | 7.2 | 28c9b3c5dc35 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
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 acp_hw_fini during amdgpu driver teardown (amdgpu_pci_remove/amdgpu_driver_unload_kms), reachable via local PCI unbind/module unload or a failed amdgpu init cleanup after opening a DRM render node; there is no network-facing entry point.
- AC:LAttack complexity, low
- Once the AMDGPU ACP block has been initialized, calling acp_hw_fini deterministically frees acp_genpd without unregistering it from the global genpd list; no race or special memory layout is required to leave a dangling list entry.
- PR:LPrivileges required, low
- Unprivileged users with access to /dev/dri/renderD* can autoload amdgpu and trigger the fini path if initialization fails after ACP setup; the same bug also fires on privileged driver unload/hot-unplug teardown of AMDGPU on ACP-capable APUs (Carrizo/Stoney).
- UI:NUser interaction, none
- Exploitation does not require any victim interaction such as clicking links or mounting filesystems; triggering driver teardown or a failed init cleanup is sufficient once the attacker can open the DRM device or unload the driver.
- S:UScope, unchanged
- The use-after-free corrupts kernel heap metadata/objects in the same kernel security domain during AMDGPU/ACP teardown; it does not by itself cross VM, container, or IOMMU boundaries to impact a separate authority.
- C:HConfidentiality impact, high
- Freeing the generic_pm_domain while it remains linked on the global gpd_list is a kernel use-after-free; subsequent genpd list walks can read attacker-influenced freed memory, enabling information disclosure and kernel pointer leaks.
- I:HIntegrity impact, high
- The dangling genpd entry allows the power-domain core to perform reads/writes through a freed acp_pm_domain/generic_pm_domain object, providing a standard heap UAF primitive that can be developed into arbitrary kernel memory corruption or code execution.
- A:HAvailability impact, high
- Dereferencing the freed genpd from the global list during later power-management operations can cause kernel oops/panic or hang, and the UAF can be leveraged for a reliable denial-of-service even when full exploitation is not attempted.