Description
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)
Published: 2026-08-10
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises when the AMDGPU driver fails to unmap a device aperture during normal unload, leaving an obsolete entry in the x86 PAT interval tree. This orphaned mapping can interfere with subsequent memory remapping operations, producing ioremap errors and causing the driver to report a discovery failure. As a result, system stability is affected, potentially leading to kernel panics or denial of service if the corrupted mapping persists during device reloads.

Affected Systems

The issue affects any Linux kernel running the upstream AMDGPU driver. No specific kernel version range is listed in the CNA data, so all kernel releases that include the affected amdgpu driver code are potentially vulnerable until updated.

Risk and Exploitability

The CVSS and EPSS details are not provided, and the vulnerability is not listed in the CISA KEV catalog. Because the bug is limited to kernel code that executes with kernel privileges, exploitation requires local access to the affected device driver and is likely constrained to systems with AMDGPU hardware. The lack of a measurable EPSS score suggests limited public exploitation data, but the technical impact (memory resource leak and potential for kernel instability) warrants prompt attention.

Generated by OpenCVE AI on August 10, 2026 at 13:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the recent commit that switches to devres‑managed mappings (e.g., kernel 6.9 or later when the patch is merged).
  • Verify that the kernel build configuration enables the AMDGPU driver with devres management; rebuild if necessary.
  • After applying the kernel update, monitor dmesg for any AMDGPU discovery errors and confirm that the "amdgpu: discovery failed" messages no longer appear.

Generated by OpenCVE AI on August 10, 2026 at 13:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
Description 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)
Title drm/amdgpu: fix aperture mapping leak
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-10T11:58:18.093Z

Reserved: 2026-07-30T09:28:09.368Z

Link: CVE-2026-68102

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-10T13:45:03Z

Weaknesses

No weakness.