Cloudanix VulnDB

CVE-2026-68234

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux graphics driver for AMD cards can slowly leak memory when the computer wakes from sleep or restarts graphics processing, eventually hurting performance.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Repeated calls to amdgpu_bo_create_reserved with a non-NULL BO pointer unconditionally increment pin_count via amdgpu_bo_pin without a matching unpin on teardown, preventing TTM from evicting or moving the BO and causing permanent buffer object leaks.

Why it matters to the business

Systems using AMD GPUs may experience gradual memory exhaustion or degraded graphics performance during repeated resume, firmware reload, or driver start cycles, increasing operational overhead and potential downtime on affected hardware.

How an attack unfolds

An attacker with local access triggers repeated resume or cp_resume operations that invoke amdgpu_bo_create_reserved on the same firmware BO pointer, accumulating pin references until TTM memory management is impaired and system resources are exhausted.

How to fix it

Update the Linux kernel to a version containing the fix from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf (or equivalent backport) so that pinning occurs only once at BO creation.

How to confirm the fix worked

Confirm the kernel source contains the conditional pinning logic change in amdgpu_bo_create_reserved; test by exercising resume/firmware reload paths and verifying pin_count returns to zero after teardown.

Typical attack path

  1. Obtain local code execution on a Linux system with AMDGPU driver
  2. Trigger device suspend/resume or firmware reload paths (e.g., via power management or driver restart)
  3. Cause amdgpu_bo_create_reserved to be called repeatedly with the same non-NULL BO pointer
  4. Accumulate pin_count without corresponding unpins, exhausting TTM-managed memory
  5. Observe BO leaks and potential denial-of-service effects on graphics subsystem

How to detect it

Inspect kernel logs for repeated amdgpu BO pin operations without matching unpins during suspend/resume cycles; correlate with rising pin_count values or TTM eviction failures in debug output.

What your security team should do

  • Prioritize kernel updates on all AMD GPU-equipped Linux systems within standard patch cycles
  • Monitor upstream stable kernel releases for the backported fix
  • Review power-management and driver-restart scripts for unnecessary repeated firmware loads

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)

Affected packages

Ecosystem Package Introduced Fixed