CVE-2026-97424: drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/ras: add rassuspend callback and use it for cpeccerrorirq
cpeccerrorirq is acquired in amdgpugfxraslateinit() but released in gfxv90hwfini(), so the put site has to query amdgpuirqenabled() because the get is skipped on SR-IOV VF.
raslateinit / rasfini have no suspend counterpart, so move the put to amdgpugfxrassuspend() / amdgpugfxrasfini() and add a matching rassuspend callback that is invoked from amdgpurassuspend() before disableallfeatures(). The get and put now sit in the same place and check the same condition (not VF, funcs registered), no refcount querying needed.
An active flag gates rasfini so the suspend-then-unload-without-resume path falls into amdgpurasblocklatefinidefault() instead of double-releasing what rassuspend already cleaned up.
Drop the cpeccerrorirq put from gfxv90hwfini(). gfxv80 manages cpeccerrorirq locally and is unaffected; no other GFX generation has this IRQ.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue concerns AMDGPU GFX v9 hardware using the RAS path for cp_ecc_error_irq. GFX v8 manages this IRQ locally and is stated to be unaffected; no other GFX generation has this IRQ.
Does SR-IOV virtual-function use trigger the affected IRQ handling?
No. Acquisition of cp_ecc_error_irq is skipped for SR-IOV virtual functions, and the fix makes acquisition and release use the same non-VF condition.
What lifecycle scenario does the fix address?
It addresses suspend handling and the suspend-then-unload-without-resume path. The added suspend callback releases the IRQ during suspend, while an active flag prevents ras_fini from releasing it a second time during unload.