Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-68237

CVE-2026-68237: Linux Kernel AMDGPU DoS Vulnerability

CVE-2026-68237 is a denial of service flaw in the Linux kernel AMDGPU driver that causes indefinite fence waits during GPU reset, potentially wedging the system. This article covers technical details, impact, and mitigation.

Published:

CVE-2026-68237 Overview

CVE-2026-68237 is a Linux kernel vulnerability in the AMD GPU (amdgpu) driver's user queue (userq) subsystem. The flaw causes an indefinite fence wait during GPU reset when user queues are in states other than MAPPED. The pre_reset routine only force-completes fences of MAPPED queues, leaving queues in intermediate states (such as mid-eviction) with pending last_fence references. After a GPU reset, those fences never signal, causing the eviction and suspend worker (amdgpu_evf_mgr_flush_suspend) to block indefinitely and wedge the system.

Critical Impact

A GPU reset triggered while an amdgpu user queue is mid-eviction leaves the kernel eviction worker blocked in dma_fence_wait_timeout, hanging tasks for more than 120 seconds and rendering the machine unresponsive.

Affected Products

  • Linux kernel builds shipping the amdgpu driver with user queue support
  • Systems using AMD GPUs with the drm/amdgpu/userq subsystem enabled
  • Distributions incorporating the affected upstream commits prior to backport 9102b39fa924dcc3dc75a3137bfa9633c40b88c0

Discovery Timeline

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

Technical Details for CVE-2026-68237

Vulnerability Analysis

The defect resides in the AMD GPU user queue reset path. During a GPU reset, pre_reset iterates over user queues to force-complete outstanding fences so that dependent workers can make forward progress. The original logic restricted this force-completion to queues in the MAPPED state. Queues in transitional states, such as mid-eviction, retained a pending last_fence reference.

When the GPU reset completes, those pending fences are never signalled. The eviction/suspend worker amdgpu_eviction_fence_suspend_worker calls amdgpu_userq_evict, which invokes dma_fence_wait_timeout on the stale fence. The worker blocks indefinitely. Process teardown through amdgpu_evf_mgr_flush_suspend also stalls, producing the reported kernel hung-task warning after 120 seconds.

Root Cause

The root cause is incomplete state coverage in the fence force-completion logic of pre_reset. By gating force-completion on the MAPPED queue state, the driver leaves fences owned by queues in other lifecycle states (eviction, suspend, unmapped) referenced but unsignalled after reset. This is a kernel driver logic flaw producing a denial-of-service condition through deadlock on a dma_fence object.

Attack Vector

The issue is triggered by a GPU reset that occurs while any user queue is not in the MAPPED state. In practice, reset events can be induced by faulting or misbehaving GPU workloads, driver-detected hangs, or eviction pressure under memory contention. A local user running graphics or compute workloads can plausibly reach the vulnerable state, resulting in a system-wide hang. No remote vector is documented.

No public exploit code is available. The upstream fix, cherry-picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0, force-completes every queue's fence regardless of state, while keeping the unmap and mark-hung step gated on MAPPED because unmapping an unmapped queue is invalid. Reference commits are available at Kernel Git Commit 3085ae8 and Kernel Git Commit 5d75ec2.

Detection Methods for CVE-2026-68237

Indicators of Compromise

  • Kernel log entries reading INFO: task kworker/<N>:<M> blocked for more than 120 seconds with Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu].
  • Call traces containing dma_fence_wait_timeout, amdgpu_userq_evict, and amdgpu_eviction_fence_suspend_worker after a GPU reset event.
  • Unresponsive graphical sessions or compute jobs following an amdgpu reset message in dmesg.

Detection Strategies

  • Monitor dmesg and journalctl -k for amdgpu reset messages followed by hung-task warnings referencing the eviction worker.
  • Alert on systems where khungtaskd reports blocked kernel workers with amdgpu in the workqueue name.
  • Correlate GPU reset events with subsequent process teardown stalls to identify recurrent triggers.

Monitoring Recommendations

  • Ship kernel logs from Linux endpoints and servers to a centralized logging platform and build alerts for the amdgpu_eviction_fence_suspend_worker call trace signature.
  • Track kernel version inventories to identify hosts still running pre-patch amdgpu code.
  • Baseline GPU reset frequency across the fleet so anomalous spikes are investigated before they escalate to system hangs.

How to Mitigate CVE-2026-68237

Immediate Actions Required

  • Update to a Linux kernel release incorporating the upstream fix cherry-picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0.
  • Prioritize patching AMD GPU hosts running graphics or compute workloads that regularly trigger evictions or resets.
  • Reboot affected systems after upgrading the kernel to ensure the patched amdgpu module is loaded.

Patch Information

The fix is delivered via the referenced stable kernel commits: Kernel Git Commit 3085ae8 and Kernel Git Commit 5d75ec2. The patch modifies pre_reset to force-complete every user queue's fence regardless of state, while keeping the unmap and mark-hung step gated on the MAPPED state.

Workarounds

  • Avoid workloads that trigger frequent GPU resets on unpatched kernels, including unstable compute jobs and drivers known to fault.
  • Disable the amdgpu user queue path where operationally acceptable until the kernel is updated.
  • Where a hang is observed, capture the full kernel call trace and reboot; do not attempt to unmap queues manually, since unmapping a non-MAPPED queue is invalid.
bash
# Verify running kernel and amdgpu module version
uname -r
modinfo amdgpu | grep -E '^(version|srcversion|filename):'

# Inspect recent GPU reset and hung-task events
dmesg -T | grep -E 'amdgpu|hung_task|dma_fence_wait_timeout'
journalctl -k --since '24 hours ago' | grep -i amdgpu

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.