This is a use-after-free in the AMDGPU driver's power domain teardown. The bug: acp_genpd memory gets freed before it's unregistered from the global power domain list. The fix is two lines — swap the order so pm_genpd_remove() executes before kfree(). That simplicity is exactly what makes this dangerous.
The genpd API permits this unsafe sequence. There is no compiler warning, no runtime assertion, no documentation footnote warning that unregister-before-free is mandatory. Developers must either know this from experience, read the fine print on pm_genpd_remove(), or have it caught in review. That's a design failure masquerading as a coding error.
What matters is not the two-line fix but what sits beneath it. This exact pattern — resource freed before unregistration creates a UAF window — has appeared in PCI power management, devfreq, and multiple DRM subsystems across kernel versions. Each fix is two lines. Each post-mortem calls it an isolated incident. The pattern persists because the API treats registration and unregistration as symmetrical when they are asymmetric: unregister is a synchronization barrier, not a cleanup step, and that distinction lives in nobody's mental model until exploitation costs them.
The blast radius here exceeds typical kernel bugs. AMDGPU manages DMA transactions, physical memory apertures, and interrupt routing. Exploitation through this UAF gives kernel execution through a subsystem that can reach physical memory via DMA, manipulate IOMMU mappings, and touch hypervisor boundaries on SR-IOV systems. CVSS 7.8 reflects a ceiling effect — there's nowhere to go after kernel compromise except full machine control, and this bug provides that access through a hardware-adjacent vector.
Check your kernel version. If you're running an upstream kernel between the introduction of ACP genpd support and the backport window, you're exposed. If you're on a downstream LTS tree that hasn't pulled this cherry-pick, your exposure compounds with each day you defer the update. The CVE landed in 2026, meaning this vulnerability sat silently through at least one kernel development cycle before disclosure.
The upstream commit patches the symptom. It does not add comments explaining why ordering matters, does not extend genpd API documentation, and does not include test coverage for this failure class. That is the real risk: the fix scars over the wound without scarring the tissue to prevent reopening. Review other genpd consumers in your codebase for the same ordering dependency. Assume similar bugs exist in adjacent code paths until proven otherwise. The two-line fix solves this instance; the architectural gap it exposes demands sustained attention.