https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 20:54:26 +0000 https://vulnerability.circl.lu/vuln/cve-2026-89812 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/amdgpu: force complete the MES ring fences on reset</p> <p>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.</p> <p>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:</p> <p>amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block &lt;gfx_v11_0&gt; failed -110 amdgpu: GPU reset end with ret = -110</p> <p>Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq.</p> <p>v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/amdgpu: force complete the MES ring fences on reset</p> <p>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.</p> <p>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:</p> <p>amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block &lt;gfx_v11_0&gt; failed -110 amdgpu: GPU reset end with ret = -110</p> <p>Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq.</p> <p>v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].</p> https://vulnerability.circl.lu/vuln/cve-2026-89812