CVE-2026-68102

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
10/08/2026
Last modified:
17/08/2026

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix aperture mapping leak<br /> <br /> amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver<br /> fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to<br /> always return false, so iounmap(aper_base_kaddr) never runs on normal<br /> driver unload, leaving an orphaned entry in the x86 PAT interval tree.<br /> <br /> On connected_to_cpu hardware, the aperture is mapped write-back (WB) via<br /> ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC)<br /> over the same range. The WC vs WB conflict causes:<br /> <br /> ioremap error for 0x..., requested 0x1, got 0x0<br /> amdgpu: discovery failed: -2<br /> <br /> Fix by switching to devres-managed mappings so cleanup is guaranteed<br /> regardless of drm_dev_enter() state:<br /> <br /> - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For<br /> IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut,<br /> returning __va(offset) from the existing kernel direct map. No new<br /> ioremap VA or PAT entry is created, so there is nothing to orphan.<br /> <br /> - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action,<br /> guaranteeing cleanup at device_del() time.<br /> <br /> Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio()<br /> since the mapping is now devres-owned.<br /> <br /> v2: Remove redundant x86_64 guard (Lijo)<br /> <br /> (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)

Impact