CVE-2026-68102

What it actually does

This is a Linux kernel AMDGPU driver cleanup flaw that can leave an aperture memory mapping registered after the driver is unloaded. Because the mapping is not released correctly, a later driver reload can attempt to map the same physical range with incompatible cache attributes, causing x86 PAT mapping conflicts. The practical result is AMDGPU initialization failure, commonly with IP discovery failure, which can make the GPU unavailable until the system is rebooted or the stale mapping state is otherwise cleared. The impact is denial of service rather than code execution or data exposure.

Why it matters to the business

Systems that depend on AMD GPUs may lose graphics, compute, acceleration, or display functionality after an AMDGPU driver unload/reload cycle. This can disrupt workstations, GPU-backed workloads, visualization systems, remote desktops, and other services relying on GPU availability. The issue was published recently and is not listed in CISA KEV, has no known ransomware association, and currently has no reported exploit maturity, so urgency is primarily driven by operational exposure rather than active mass exploitation.

How an attack unfolds

An attacker or failure condition must cause the AMDGPU driver to unload and then reload on affected Linux systems. During unload, the driver calls the DRM unplug path before cleanup routines that would normally release the aperture mapping. Because the cleanup path is bypassed, the mapping remains orphaned in the PAT interval tree. When the driver is later reloaded, AMDGPU initialization attempts to map the same aperture range using a different memory cache mode. The kernel detects the conflicting mapping attributes and rejects the new mapping. AMDGPU discovery then fails, leaving the GPU driver unable to initialize and the GPU unavailable. In most environments this requires local administrative capability, module-management privileges, or an operational path that can trigger driver unload/reload, such as maintenance automation, GPU reset workflows, or driver updates.

How to fix it

Apply a Linux kernel update that includes the AMDGPU fix for the aperture mapping cleanup issue. The fix changes the relevant mappings to device-resource-managed mappings so cleanup is guaranteed during device removal, and removes the now-invalid manual unmap path. If vendor package fixed versions are not yet available, track the Linux distribution, appliance, or kernel vendor advisory for the backported fix associated with upstream commit d871e99879cb5fd1fa798b006b4888887e63a17a. As interim mitigation, avoid unnecessary AMDGPU driver unload/reload cycles on affected systems, avoid repeated GPU reset workflows where possible, schedule kernel or driver maintenance windows carefully, and reboot affected systems that have already encountered the mapping conflict to restore GPU availability.

How to confirm the fix worked

Confirm exposure by checking whether the system runs the AMDGPU kernel driver on a kernel build that predates the vendor fix. Validate remediation by installing the corrected kernel, rebooting into it, and confirming that AMDGPU can be unloaded/reloaded or the device can be removed/re-added without ioremap cache-attribute conflict messages or discovery failure. Review kernel logs with journalctl or dmesg for AMDGPU initialization errors before and after patching. A successful fix should eliminate repeated messages indicating an ioremap cache-mode conflict and `amdgpu: discovery failed: -2` during driver reload.

Typical attack path

1. Identify a Linux system using the AMDGPU kernel driver and affected kernel code.
2. Obtain local privileges sufficient to unload or reload kernel modules, or abuse an operational mechanism that triggers AMDGPU driver teardown and reinitialization.
3. Trigger normal AMDGPU driver unload, removal, reset, or update behavior.
4. Cause or wait for AMDGPU driver reload or device rediscovery.
5. The stale aperture mapping conflicts with the new mapping request, causing ioremap/memremap failure.
6. AMDGPU initialization fails and GPU functionality remains unavailable until remediation or reboot.

How to detect it

Look for evidence of failed AMDGPU reinitialization after driver unload, reload, device removal, GPU reset, suspend/resume, or kernel maintenance activity. Primary log sources are kernel logs from `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, and distribution-specific system logs. Search for ioremap cache conflict messages, AMDGPU discovery failures, AMDGPU probe failures, DRM unplug/remove events, and recent module unload/reload activity involving `amdgpu`. Correlate these events with administrative commands such as `modprobe -r amdgpu`, `rmmod amdgpu`, package manager kernel updates, GPU reset tooling, or device unbind/rebind operations under sysfs. There are no known public threat actors or ransomware campaigns associated with this issue; investigation should focus on local administrative activity, automation, failed maintenance, or intentional disruption by a privileged user.

• ioremap error for
• requested 0x1, got 0x0
• amdgpu: discovery failed: -2
• amdgpu_pci_remove
• amdgpu_ttm_fini
• amdgpu_device_unmap_mmio
• modprobe -r amdgpu
• rmmod amdgpu
• /sys/bus/pci/drivers/amdgpu/unbind
• /sys/bus/pci/drivers/amdgpu/bind
• drm_dev_unplug
• MEMREMAP_WC
• MEMREMAP_WB

What your security team should do

• Inventory Linux systems using AMDGPU, especially GPU workstations, compute nodes, visualization hosts, and systems where GPU availability is operationally important.
• Prioritize patching systems that frequently reload GPU drivers, perform GPU reset operations, run rolling kernel updates, or host critical GPU-backed workloads.
• Monitor kernel and system logs for AMDGPU discovery failures and ioremap cache-attribute conflicts after driver unload/reload events.
• Restrict local administrative access and kernel module management permissions to reduce the likelihood of intentional GPU denial of service.
• Coordinate with platform, endpoint, and operations teams to schedule kernel updates and reboots because remediation requires running a fixed kernel build.
• If symptoms are observed before patching, reboot the host to restore GPU service and then apply the fixed kernel as soon as available.