CVE-2026-68102 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix aperture mapping leak
amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to always return false, so iounmap(aper_base_kaddr) never runs on normal driver unload, leaving an orphaned entry in the x86 PAT interval tree.
On connected_to_cpu hardware, the aperture is mapped write-back (WB) via ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC) over the same range. The WC vs WB conflict causes:
ioremap error for 0x..., requested 0x1, got 0x0 amdgpu: discovery failed: -2
Fix by switching to devres-managed mappings so cleanup is guaranteed regardless of drm_dev_enter() state:
- connected_to_cpu path: devm_memremap(MEMREMAP_WB). For IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut, returning __va(offset) from the existing kernel direct map. No new ioremap VA or PAT entry is created, so there is nothing to orphan.
- dGPU path: devm_ioremap_wc() registers iounmap() as a devres action, guaranteeing cleanup at device_del() time.
Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio() since the mapping is now devres-owned.
v2: Remove redundant x86_64 guard (Lijo)
(cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in question affects the amdgpu driver within the Linux kernel, specifically addressing a memory mapping leak that occurs during normal driver unload operations. This issue stems from improper cleanup of aperture mappings when the drm/amdgpu driver is removed from the system, creating orphaned entries in the x86 PAT (Page Attribute Table) interval tree that can lead to system instability and resource exhaustion.
The core technical flaw manifests in the sequence of function calls within amdgpu_pci_remove() where drm_dev_unplug() is invoked before the driver's fini routines execute. This ordering causes drm_dev_enter() within amdgpu_ttm_fini() to consistently return false, which prevents the iounmap(aper_base_kaddr) operation from executing during normal driver unload scenarios. The consequence is that aperture mappings remain active in memory even after the driver has been unloaded, creating persistent references in the kernel's memory management subsystem.
This vulnerability particularly impacts systems with connected_to_cpu hardware configurations where the aperture is initially mapped with write-back (WB) attributes using ioremap_cache(). When the driver is reloaded, IP discovery processes attempt to remap the same memory range using memremap() with MEMREMAP_WC attributes, creating a direct conflict between WC and WB memory types. The resulting error message "ioremap error for 0x..., requested 0x1, got 0x0" indicates this fundamental incompatibility that prevents proper driver initialization.
The mitigation strategy implemented addresses the root cause by transitioning to devres-managed memory mappings that guarantee proper cleanup regardless of the drm_dev_enter() return state. For connected_to_cpu hardware paths, the solution employs devm_memremap() with MEMREMAP_WB attributes, which leverages the kernel's existing direct map for IORESOURCE_SYSTEM_RAM ranges through try_ram_remap() functionality. This approach avoids creating new ioremap virtual addresses or PAT entries that could become orphaned, effectively eliminating the leak scenario.
For discrete GPU (dGPU) configurations, the fix implements devm_ioremap_wc() which registers iounmap() as a device resource action, ensuring cleanup occurs automatically at device_del() time rather than relying on conditional execution based on drm_dev_enter() return values. This change also removes the redundant iounmap(aper_base_kaddr) call from amdgpu_device_unmap_mmio() since the mapping is now exclusively managed by the device resource framework.
This vulnerability aligns with CWE-404, which covers improper resource release or cleanup, and represents a classic case of resource leak in kernel memory management. The fix demonstrates adherence to secure coding practices by ensuring deterministic cleanup through proper device resource management, preventing potential denial-of-service conditions that could arise from persistent memory mappings. The solution also addresses ATT&CK technique T1070.004 related to "Indicator Removal on Host" by ensuring complete cleanup of kernel resources during driver removal operations, preventing artifacts that could interfere with system stability or subsequent driver loads.