CVE-2026-89812: Linux Kernel DRM AMDGPU Privilege Escalation

CVE-2026-89812 Overview

CVE-2026-89812 is a Linux kernel vulnerability in the AMD GPU driver (drm/amdgpu). The flaw affects the Micro Engine Scheduler (MES) ring fence handling during GPU reset operations. Because the MES scheduler ring has no_scheduler = true, the force-completion loop in amdgpu_device_pre_asic_reset() skips it. The polling fence value lives in Graphics Translation Table (GTT) writeback memory and survives a MODE1 reset, while fence_drv.sync_seq continues advancing per packet. When MES itself triggers the reset, subsequent submissions poll forever on a sequence number that is never written back, wedging the system on a second reset.

Critical Impact
The unresolved fence state causes GPU resume to fail with -110 timeout errors, leading to a denial-of-service condition where the graphics subsystem becomes permanently unrecoverable until reboot.

Affected Products

Linux kernel drm/amdgpu driver
Systems using AMD GPUs with MES (Micro Engine Scheduler) firmware
Kernels prior to the fix commits 48dc279c3010 and ebe7542553d0

Discovery Timeline

2026-09-16 - CVE-2026-89812 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-89812

Vulnerability Analysis

The vulnerability resides in the AMD GPU driver's reset path handling of the MES scheduler ring. The MES ring is instantiated without a Direct Rendering Manager (DRM) scheduler attached, so the force-completion loop in amdgpu_device_pre_asic_reset() bypasses it during Advanced SIMD Instruction Compute (ASIC) reset preparation. This creates an inconsistency between hardware fence state and software sequence tracking.

MES uses a polling fence whose hardware value resides in writeback (wb) memory backed by GTT. This memory survives a MODE1 reset. The software counter fence_drv.sync_seq increments for every submitted packet regardless of reset activity. When MES stops responding and triggers a reset, timed-out packets have already advanced sync_seq past the last hardware fence value MES actually wrote back.

After resume, the first MES submission polls indefinitely on a sequence number that will never be written. The failure manifests as ring buffer exhaustion and IP block resume failure. This categorizes the issue as a Kernel Vulnerability with denial-of-service impact.

Root Cause

The root cause is the omission of MES scheduler rings from the fence force-completion loop during ASIC reset. Because these rings lack a DRM scheduler, existing cleanup code paths bypass them, leaving stale sequence tracking after reset.

Attack Vector

This is a local reliability defect triggered by MES firmware unresponsiveness that leads to GPU reset. There is no evidence of remote exploitation. Observed error output includes:

amdgpu: MES ring buffer is full.
amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110)
amdgpu: resume of IP block <gfx_v11_0> failed -110
amdgpu: GPU reset end with ret = -110

See the upstream fix for implementation specifics in Linux Kernel Commit 48dc279 and Linux Kernel Commit ebe75425.

Detection Methods for CVE-2026-89812

Indicators of Compromise

Kernel log entries containing MES ring buffer is full messages
ring gfx_0.0.0 test failed (-110) errors following a GPU reset event
resume of IP block <gfx_v11_0> failed -110 in dmesg output
Repeated GPU reset end with ret = -110 messages indicating recovery failure

Detection Strategies

Monitor dmesg and journalctl -k for amdgpu reset failure patterns and -110 (ETIMEDOUT) return codes
Correlate GPU reset events with subsequent MES ring buffer full messages to identify wedge conditions
Track kernel version and amdgpu driver build against the fix commits on all Linux hosts with AMD GPUs

Monitoring Recommendations

Ingest kernel logs into a centralized logging platform and alert on amdgpu error signatures
Include GPU driver version in host inventory to identify systems missing the patched kernel
Track host uptime and unexpected graphics subsystem restarts on workstations, render farms, and compute nodes

How to Mitigate CVE-2026-89812

Immediate Actions Required

Identify Linux hosts running amdgpu with MES-capable AMD GPUs, including workstations and GPU compute nodes
Apply the upstream kernel patches or upgrade to a distribution kernel that includes both fix commits
Reboot affected systems after patching to load the corrected driver

Patch Information

The fix forces completion of MES scheduler ring fences alongside standard scheduler rings, realigning the hardware fence to sync_seq. Version 2 of the patch extends coverage to all XCCs (one scheduler ring each) rather than only mes.ring[0]. Apply the patches referenced in Linux Kernel Commit 48dc279 and Linux Kernel Commit ebe75425, or update to a stable kernel release incorporating these commits.

Workarounds

No supported software workaround exists; the fix requires patching the amdgpu driver source
Reboot affected hosts to recover from a wedged GPU state until the patched kernel is deployed
Where feasible, avoid workloads that stress the MES scheduler on unpatched kernels to reduce reset frequency

bash

# Verify running kernel and amdgpu module version
uname -r
modinfo amdgpu | grep -E '^(version|srcversion|filename)'

# Check for the error signatures in kernel logs
journalctl -k --no-pager | grep -E 'amdgpu.*(MES ring buffer|failed -110)'