CVE-2026-68234 AMDGPU Memory Pin Leak Fixed in Linux

The CVE was added to the NVD on August 10, 2026, sourced from kernel.org, and tracks a correction in

. The NVD record currently has no CVSS 4.0 or CVSS 3.x score, no assigned CWE, and no vendor-supplied exploit scenario. That absence is important: this is a real defect with a CVE identifier, but the public record does not support treating it like a remotely exploitable Radeon driver flaw.

The leak occurs when an existing AMDGPU buffer is reused​

The affected routine,

, is intended to create a reserved buffer object—known in the driver as a BO—for kernel use. It accepts a pointer to an existing BO pointer. If that pointer is null, the function creates the buffer; if it already points to a buffer, creation is skipped.

The problem was that the old code did not similarly distinguish between creating a BO and pinning one. It skipped allocation when a BO already existed, but still reserved, pinned, allocated GART backing for, and mapped that same existing object. Each subsequent call added another pin reference.

Pinning is a memory-management constraint rather than a simple bookkeeping flag. A pinned BO is not freely relocatable by the TTM memory manager, the Linux subsystem that manages GPU memory placement and eviction. The matching teardown path, however, unpinned only once. After repeated reuse, the pin count could never return to zero, leaving the object effectively stuck in place.

The kernel.org advisory specifically identifies firmware buffers stored on the AMDGPU device structure as an example. Those buffers can be reloaded during resume,

, or driver start paths when

is in use. A machine that repeatedly suspends and resumes, or repeatedly reinitializes the relevant GPU firmware path, is therefore more exposed to the leak than a system that boots once and remains up.

This is also why the bug is more serious than a small counter imbalance. The leaked pin references can stop TTM from reclaiming memory that it would normally be able to move, swap, or evict. Over time, that can turn a recoverable driver-memory allocation into a persistent pressure point for the graphics stack.

The final patch is deliberately small​

The upstream fix originated in commit

and was later cherry-picked into supported stable branches. Instead of restructuring the function into several new helpers, the final correction moves the pinning operation into the block that runs only when a BO is newly created.

That detail reflects review on the AMD graphics mailing list. The initial proposal split the routine into separate create-and-pin and access-and-map helpers, but AMDGPU maintainer Christian König argued that the safer, clearer repair was simply to make pinning conditional on creation. The final patch follows that recommendation.

The repaired behavior is straightforward:

• A newly allocated BO is reserved and pinned once, as before.
• An existing BO can still be reserved and mapped again when required.
• Repeated calls with the same non-null BO pointer no longer increase its pin count.
• The existing one-time teardown can again bring the pin count to zero and let TTM manage the object normally.

That distinction is the heart of the fix. Mapping CPU or GPU access to an existing object may need to occur again after a resume path; taking another long-lived pin reference does not.

The patch does not claim to repair a corrupted user-space allocation, a Radeon firmware-image validation issue, or a flaw in the Windows display stack. Administrators seeing a CVE number alongside “AMDGPU” should resist collapsing those separate components into one problem.

Fixed upstream versions are already defined​

Kernel.org’s CVE data identifies four stable release floors that contain the repair:

The original upstream fix is present in Linux 7.2-rc4. Systems below those release points are listed as affected in the NVD’s current machine-readable data, beginning with the commit that introduced the vulnerable behavior.

There is an operational trap here: an installed distribution kernel can contain the fix even if

does not show one of those exact version numbers. Enterprise and long-term-support distributions routinely backport targeted fixes while retaining their own kernel release string and package revision. Conversely, a custom kernel may advertise a newer-looking base version while omitting a stable backport or carrying a different patch set.

For that reason, the right verification sequence is not “compare the first three digits and declare victory.” Check the installed kernel version, then check the distribution’s kernel changelog or security advisory for CVE-2026-68234 or the upstream commit. For self-built kernels, inspect whether the conditional pinning change is present in

.

A quick initial check remains useful:

A machine running a stock kernel below the fixed floor for its branch should be updated through its normal package-management path. Systems that rely on an AMDGPU device for desktop rendering, compute, virtualization, or persistent graphical workloads should schedule the update rather than waiting for an unrelated graphics symptom to appear.

Windows systems are mostly outside the affected path​

For ordinary Windows 10 and Windows 11 installations, CVE-2026-68234 does not apply to AMD Software: Adrenalin Edition, the Windows AMD display miniport driver, or the Windows DirectX kernel graphics subsystem. This is a Linux kernel AMDGPU source-tree defect. Updating a Windows Radeon driver will not add the Linux patch, and applying a Linux kernel update will not alter the Windows display driver.

The Windows-specific question is WSL 2. WSL 2 does run a genuine Linux kernel in a lightweight virtual machine, so kernel CVEs can matter to Windows users. But this particular issue has a narrower scope than the product name suggests.

Microsoft documents that WSL GPU access is routed through the

device to the Windows GPU stack. In the standard WSL 2 GPU-acceleration model, an AMD Radeon card used for DirectML, Linux GUI acceleration, or supported compute work is exposed through that virtualization path rather than being driven as a physical PCI device by the Linux

kernel driver. A Windows user running GPU-accelerated workloads in WSL should therefore not assume that use of an AMD GPU means the vulnerable AMDGPU code is active.

That does not make kernel maintenance optional. Microsoft’s WSL documentation says the WSL kernel is serviced separately and can be updated with:

wsl --update
wsl --status

But for this CVE, the relevant question is whether the WSL kernel is actually booting and binding the Linux AMDGPU driver to hardware. On a conventional WSL 2 installation, the answer is generally no: the graphics route is

, not native AMDGPU device management. The more plausible Windows-adjacent cases are custom WSL kernels, nonstandard virtualization arrangements, Linux dual-boot installations, or Hyper-V/Linux guests with direct GPU assignment.

Treat this as a stability fix with a security tracking number​

The NVD’s current record describes a BO leak, not an attacker-controlled trigger. No CVSS score has been assigned as of August 11, 2026, and the advisory does not identify a privilege-escalation, denial-of-service-over-the-network, or data-exposure path. That is a material difference from many kernel CVEs that warrant emergency remediation based on an immediate security boundary risk.

Still, the fix deserves routine priority on native Linux systems using AMDGPU. A firmware buffer that remains pinned through repeated resume or initialization cycles reduces the GPU memory manager’s ability to recover space when it needs it. The visible result could be memory pressure, failure to relocate objects, or driver behavior that becomes progressively less reliable after repeated power-state transitions.

For Windows enthusiasts and administrators, the action is narrow: update WSL normally, but do not chase this CVE through Radeon Software or Windows Update as though it were a Windows graphics-driver bulletin. For Linux machines with AMD GPUs, move to Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, or a vendor kernel package that explicitly backports the correction.