VulnerabilityPublished 16 Sep 2026Updated 21 Oct 2026

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

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in ebe7542553d008e2285e0fbba0c63f0295a7e694 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.2% chance of exploitation in 30 days – higher than 10% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in ebe7542553d008e2285e0fbba0c63f0295a7e694, c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f, 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 +1

Exploitation evidence

Disclosed: evidence found.
CVE published 16 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to ebe7542553d008e2285e0fbba0c63f0295a7e694, c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f, 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5 or 7d722821e2f626c4e34c8510f0ce1d6f10c77a3b.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 34e087e8920e635c62e2ed6a758b0cd27f836d13, < ebe7542553d008e2285e0fbba0c63f0295a7e694	Fixed in ebe7542553d008e2285e0fbba0c63f0295a7e694
LinuxLinux	Affected ≥ 34e087e8920e635c62e2ed6a758b0cd27f836d13, < c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f	Fixed in c48d5a4d2863e56a6692ecb6cd6c32404f40cd0f
LinuxLinux	Affected ≥ 34e087e8920e635c62e2ed6a758b0cd27f836d13, < 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5	Fixed in 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5
LinuxLinux	Affected ≥ 34e087e8920e635c62e2ed6a758b0cd27f836d13, < 7d722821e2f626c4e34c8510f0ce1d6f10c77a3b	Fixed in 7d722821e2f626c4e34c8510f0ce1d6f10c77a3b
LinuxLinux	Affected =6.12	Fixed in–

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

References

Community reviews

Loading reviews…