CVE-2026-68102: Linux AMDGPU Reload Failure Fixed

The newly published CVE entry, supplied by kernel.org and added to NIST’s National Vulnerability Database on August 10, identifies the vulnerable code in

and

. Its description matches the original AMD GPU mailing-list patch from Asad Kamal and a subsequent DRM fixes pull request from AMD maintainer Alex Deucher that included the change for Linux 7.2.

The important finding is that this is a driver reload and device-lifecycle failure, not evidence of a remotely exploitable GPU security bug. NVD has assigned neither CVSS v3/v4 scores nor a CWE category as of August 11. Administrators should treat the CVE identifier as a tracking mechanism for a kernel correctness fix, while still deploying the patched kernel where AMDGPU module unload/reload, device removal, GPU reset workflows, or rapid development cycles are part of normal operations.

The cleanup path was unreachable by design​

The failure begins in AMDGPU’s PCI removal path.

calls

before the driver’s finalization routines run. Later,

tried to protect its cleanup work with

.

That guard is appropriate when code must avoid touching an unplugged DRM device. Here, however, it also meant the cleanup branch that called

would always be skipped during a normal remove sequence. The aperture mapping pointer was eventually cleared, but the underlying mapping was not released.

The result was an orphaned entry in the x86 PAT, or Page Attribute Table, interval tree. PAT bookkeeping is how x86 Linux tracks memory types such as write-back and write-combining for physical address ranges. The driver had lost its handle to the mapping, while the kernel still remembered the mapping’s cache attribute.

That distinction explains why a reboot masks the issue while an unload/reload cycle exposes it. A full restart tears down the machine-wide state. Reloading AMDGPU in the same boot does not.

The bug traces back to the earlier AMDGPU change identified in the patch’s

tag:

, “drm/amdgpu: pre-map device buffer as cached for A+A config.” The CVE record lists Linux 5.13 as the first affected release, which makes this a long-lived regression rather than one introduced during the current 7.x kernel development cycle.

Why the failure shows up as a WB-versus-WC conflict​

The documented failure mode is most specific on AMD hardware where the GPU is marked

, an XGMI-oriented configuration in which the GPU aperture can correspond to system RAM. Before the fix, AMDGPU mapped that aperture with

, giving it a write-back, or WB, cache policy.

On a subsequent probe, AMDGPU’s IP-discovery path attempts to map the same physical range through

using a write-combining, or WC, policy. Linux refuses to create the second mapping because the earlier WB mapping is still live in PAT metadata. The kernel is enforcing cache-attribute consistency, but the driver’s missed cleanup leaves it with no valid way forward.

The resulting diagnostic is unusually revealing:

ioremap error for 0x..., requested 0x1, got 0x0
amdgpu: discovery failed: -2

The

value corresponds to

, but the operative failure is not that a device has vanished from PCIe. AMDGPU’s discovery sequence cannot establish the memory mapping it requires, so initialization stops. This can look like a failed driver probe after a module reload even though the GPU itself remains present.

For workstation administrators, this separates CVE-2026-68102 from the much broader class of AMDGPU ring timeouts, display engine failures, and game-related GPU resets. Updating for this CVE is sensible, but it should not be sold as a universal remedy for every

crash or black-screen report. The specific breadcrumb is an aperture mapping conflict during a post-unload reload.

The patch changes ownership, rather than repairing the old cleanup branch​

The patch does not try to reorder

or weaken

. Instead, it removes manual lifetime management for

and moves responsibility to Linux device-resource management, commonly called devres.

For the

case, AMDGPU now uses

with the WB attribute. When the aperture range is classified as

, Linux can use

and return an address from the kernel’s existing direct map. In that scenario, the driver does not create a new

virtual address or PAT entry in the first place. There is therefore no standalone mapping to leak into a later reload.

For the discrete-GPU path, AMDGPU now calls

. The device-managed helper registers the matching unmap operation as a device resource action, so it runs during device teardown independently of whether the DRM unplug state permits

.

The code also removes two manual

calls: one in

and one in

. That is a necessary part of the ownership change. Leaving manual cleanup in place after adopting devres would risk a double-unmap; merely adding devres while retaining the unreachable teardown block would have obscured which subsystem actually owned the mapping.

This is a cleaner repair than a narrowly targeted conditional. It makes the mapping’s lifetime follow the physical device lifetime, which is the resource boundary the original code was trying, and failing, to reconstruct manually.

Fixed kernel numbers matter more than the CVE’s broad affected range​

The kernel.org vulnerability data says the flaw affects Linux from version 5.13 onward, but it also identifies specific stable releases containing the remediation: 6.6.148, 6.12.101, 6.18.42, and 7.1.6, along with Linux 7.2-rc2 and later upstream development. The record references five stable-tree commits, indicating that the patch was carried into more than one maintained branch.

This produces a common vulnerability-scanner trap. A simplistic interpretation of “affected from 5.13” can flag an installation even when its distribution kernel has already backported the stable fix. Conversely, an installation with a later-looking vendor version is not automatically safe unless that vendor included the relevant stable update or an equivalent patch.

The correct operational test is the distribution’s kernel changelog, source package, or security advisory—not the major/minor number alone. This matters especially on enterprise distributions, which commonly retain an older upstream base while selectively backporting fixes. A system reporting a 6.6-derived kernel may be protected if it includes the 6.6.148 fix, while an internally maintained kernel that has not absorbed the stable patch may remain affected despite carrying other recent AMDGPU changes.

The NVD record’s version data should also be read carefully: it records upstream Linux status, not a support statement from AMD for Radeon Software, ROCm, Pro Edition packages, or any particular Linux distribution. No separate AMD advisory, product severity rating, exploitation report, or affected-card inventory is listed in the record.

Who should act now​

Users who do not unload AMDGPU and do not remove or re-enumerate the GPU during a normal uptime are unlikely to encounter the reported sequence. A standard desktop shutdown followed by a cold boot does not recreate the exact conditions that turn the orphaned PAT entry into a conflicting re-probe.

The higher-priority group is narrower:

• Systems that deliberately run modprobe -r amdgpu and reload the module for testing, troubleshooting, or graphics-stack development should move to a kernel containing the fix.
• GPU compute, passthrough, hot-plug, and device-management environments should verify their vendor kernel’s changelog, because device teardown and reinitialization are more routine there.
• Administrators supporting AMD XGMI or CPU-connected GPU configurations should consider the patch more urgent, since that is the configuration explicitly tied to the WB-versus-WC discovery failure.
• Systems with ordinary discrete Radeon GPUs should still update through normal kernel maintenance, because their aperture mapping also moves to devres ownership, but the published description does not establish the same repeatable discovery failure on every dGPU configuration.

A temporary workaround is to reboot after unloading AMDGPU rather than expecting a clean in-place reload. That avoids preserving the stale PAT state, but it is not a substitute for the fix where repeated driver reinitialization is required.

The upstream change entered AMD’s DRM fixes pull request shortly after Linux 7.2-rc1, then reached the stable branches named in the CVE record. For Windows-focused IT teams running Linux hosts, WSL-adjacent GPU test systems, Radeon compute nodes, or Linux-based virtualization infrastructure, the practical action is straightforward: inventory the running kernel, confirm whether the stable backport is present, and schedule the kernel update. The CVE is small in scope, but on the machines that hit it, the alternative is a GPU driver that cannot reliably return without a reboot.