CVE-2026-89812
N/A
Summary
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 (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet.
When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq 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 gfx_0.0.0 test failed (-110) amdgpu: resume of IP block <gfx_v11_0> 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 sync_seq.
v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < ebe7542553d008e2285e0fbba0c63f0295a7e694 | affected |
| Linux | Linux | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 | affected |
| Linux | Linux | 0 < 7.2.5 | affected |
| Linux | Linux | 7.2.5 <= 7.2.* | unaffected |
| Linux | Linux | 7.3-rc1 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/ebe7542553d008e2285e0fbba0c63f0295a7e694
- https://git.kernel.org/stable/c/48dc279c3010ac8f91b1845b2abb3a1e9943a0f5
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.