CVE-2026-80728 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
Revert "drm/amdgpu: fix aperture mapping leak"
devres teardown is LIFO. The aperture devres node was registered after the DRM device node, so devres_release_all() unmaps the aperture before the DRM device release callback fires amdgpu_device_fini_sw(). IP sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a pointer derived from aper_base_kaddr, causing a kernel page fault on probe failure / rollback:
BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu]
Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all
This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a.
(cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel vulnerability identified in the amdgpu driver involves a critical use-after-free condition triggered during device initialization failure or rollback scenarios. This issue stems from an incorrect ordering of resource cleanup operations within the kernel's managed resource framework, known as devres. The core technical flaw arises because devres teardown operates on a Last-In-First-Out basis, meaning resources are released in the reverse order of their allocation. In this specific case, the aperture mapping for the GPU was registered after the DRM device node itself. Consequently, when an error occurs during probe and the system initiates a rollback sequence via devres_release_all(), the aperture memory is unmapped before the DRM device release callback has a chance to execute its software finalization routine, amdgpu_device_fini_sw().
This ordering discrepancy leads directly to a kernel page fault because subsequent cleanup functions within the GPU driver attempt to access firmware shared structures through pointers derived from the now-unmapped aperture base address. Specifically, hardware-specific shutdown callbacks such as vcn_v4_0_sw_fini are invoked during amdgpu_device_fini_sw(). These routines rely on valid memory mappings that have already been torn down by the devres framework due to its LIFO execution model. The result is an immediate kernel panic or crash when the driver attempts to write to or read from invalid virtual addresses, effectively causing a denial of service for the system and potentially leading to data corruption if such faults occur in contexts where recovery is attempted rather than halted.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as the code accesses memory that has been deallocated or unmapped by another part of the subsystem. It also relates to CWE-362, Concurrent Execution Using Shared Resource with Improper Synchronization, although in this case the concurrency is temporal rather than parallel, involving a race between resource management layers and driver-specific cleanup logic. In terms of ATT&CK mapping, while not an exploit vector for external attackers per se, it represents a stability issue that could be leveraged locally to cause denial of service if triggered by specific hardware configurations or error conditions during device initialization.
The resolution involves reverting the commit d871e99879cb5fd1fa798b006b4888887e63a17f which introduced the aperture mapping leak fix, as that change inadvertently created this more severe stability issue by altering the initialization and cleanup order. The revert restores the previous behavior where the aperture mapping remains valid until after all software finalization steps are complete. To mitigate similar issues in future development, engineers must ensure that resource allocation orders respect dependency chains during teardown. Specifically, resources that are required for late-stage cleanup callbacks should be allocated before those dependencies or managed via explicit unmap calls within the driver's own fini functions rather than relying solely on automatic devres release ordering. System administrators and users can mitigate risk by ensuring kernel updates include this revert patch, thereby preventing crashes associated with GPU probe failures on affected hardware revisions.