CVE-2026-68234: Linux Kernel Privilege Escalation Flaw

CVE-2026-68234 Overview

CVE-2026-68234 is a resource leak vulnerability in the Linux kernel's AMD GPU (amdgpu) Direct Rendering Manager (DRM) driver. The flaw resides in the amdgpu_bo_create_reserved() function, which handles buffer object (BO) allocation for firmware buffers. When callers pass a non-NULL BO pointer, the function skips allocation but still unconditionally reserves, pins, GART-allocates, and maps the BO. Repeated invocations during resume, cp_resume, or AMDGPU_FW_LOAD_DIRECT start sequences increment pin_count without matching decrements. This causes the reference counter to never reach zero, preventing the Translation Table Manager (TTM) from moving, swapping, or evicting the affected BO.

Critical Impact
The reference leak prevents kernel memory reclamation of GPU buffer objects, degrading system stability during repeated GPU firmware reload cycles.

Affected Products

Linux Kernel (upstream drm/amdgpu driver)
Systems using AMD GPUs with firmware loaded via AMDGPU_FW_LOAD_DIRECT
Stable kernel branches referenced in the fix commits

Discovery Timeline

2026-08-10 - CVE-2026-68234 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68234

Vulnerability Analysis

The amdgpu_bo_create_reserved() function accepts a struct amdgpu_bo **bo_ptr parameter and conditionally allocates a new BO only when *bo_ptr is NULL. When *bo_ptr already points to an existing BO, the function bypasses allocation but continues executing the reservation, pinning, GART allocation, and mapping code paths. This asymmetric behavior breaks the acquire/release contract expected by callers that pass persistent BOs.

Firmware buffers stored in the amdgpu_device structure are reloaded on every resume operation, cp_resume, or engine start under direct firmware load mode. Each call routes through amdgpu_bo_pin(), which unconditionally increments pin_count. The corresponding teardown paths only invoke a single unpin, leaving the counter permanently above zero. The TTM subsystem consequently cannot migrate, swap, or evict these buffers, resulting in a memory leak that grows with each suspend/resume cycle.

Root Cause

The root cause is missing state validation in amdgpu_bo_create_reserved(). The function conflates allocation logic with post-allocation setup, applying pin operations regardless of whether the BO is new or reused. The mismatch between repeated pin increments and single unpin decrements produces an unbounded reference count on long-lived firmware buffers.

Attack Vector

Exploitation is not remote. The condition triggers during normal driver operation on systems that repeatedly reload GPU firmware, most commonly across suspend/resume cycles. The impact is availability and resource exhaustion rather than code execution or privilege escalation. See the upstream Linux kernel fix for the corrected pin lifecycle logic.

Detection Methods for CVE-2026-68234

Indicators of Compromise

Growing kernel memory consumption attributable to amdgpu BO allocations after multiple suspend/resume cycles
Elevated pin_count values on firmware BOs visible through debugfs amdgpu interfaces
TTM eviction failures logged in dmesg referencing amdgpu buffer objects

Detection Strategies

Monitor kernel version and amdgpu driver commit hashes against the fixed commits listed in the upstream references
Track memory usage trends on workstations and servers with AMD GPUs across power state transitions
Correlate GPU firmware reload events with sustained memory growth patterns

Monitoring Recommendations

Collect dmesg output and /proc/meminfo snapshots on AMD GPU hosts on a scheduled basis
Alert on unexplained kernel slab or GPU memory growth exceeding baseline after suspend/resume events
Inventory Linux endpoints running vulnerable kernel versions to prioritize patch deployment

How to Mitigate CVE-2026-68234

Immediate Actions Required

Identify Linux systems running AMD GPUs with kernels that predate the fix commits
Apply the upstream stable kernel updates that include the amdgpu_bo_create_reserved pin lifecycle fix
Schedule maintenance windows to reboot affected systems after kernel updates

Patch Information

The fix ensures that pinning occurs only during initial BO creation and that repeated calls with a non-NULL *bo_ptr do not take additional pin references. The patch is available in the upstream stable trees at commits 2f390b4c, 51eeef19, 9743f600, a2f895f3, and ba7b6444, cherry-picked from mainline commit 3ddc0ae76202c447b6aec61e907b852bc94671cf.

Workarounds

Limit suspend/resume cycles on affected systems until patches are applied
Reboot systems periodically to reclaim leaked GPU BO memory
Where feasible, switch to alternative firmware load modes that avoid repeated amdgpu_bo_create_reserved invocations on persistent BOs

bash

# Verify current kernel version and amdgpu driver status
uname -r
modinfo amdgpu | grep -E '^(version|srcversion|filename)'

# After patching, reload the driver or reboot
sudo reboot