CVE-2026-89812: drm/amdgpu: force complete the MES ring fences on reset
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: force complete the MES ring fences on reset
The MES scheduler ring has no drm scheduler (noscheduler = true), so it is skipped by the force-completion loop in amdgpudevicepreasicreset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fencedrv.syncseq keeps advancing for every packet.
When the reset is triggered because MES itself stopped responding, the timed-out packets advance syncseq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset:
amdgpu: MES ring buffer is full. amdgpu: ERROR ring gfx0.0.0 test failed (-110) amdgpu: resume of IP block <gfxv110> failed -110 amdgpu: GPU reset end with ret = -110
Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to syncseq.
v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this failure mode?
Systems using the Linux kernel amdgpu driver with MES scheduler rings are exposed when an ASIC reset occurs after MES stops responding. The fix explicitly covers all XCCs, each of which has a MES scheduler ring.
What condition triggers the post-reset failure?
MES must stop responding and cause a reset. Timed-out MES packets can advance the software sync sequence beyond the last hardware fence value retained in writeback memory, causing the first MES submission after resume to poll indefinitely.
How can I recognize that a system is affected?
Affected systems may fail to resume after a GPU reset and can become wedged on a subsequent reset. Reported messages include "MES ring buffer is full," a gfx ring test failure with -110, and "resume of IP block <gfx_v11_0> failed -110."
What does the fix change?
The fix force-completes MES scheduler ring fences during reset along with scheduler-ring fences. This realigns the hardware fence value with the advancing software sync sequence and prevents the post-reset polling hang.