UBUNTU-CVE-2026-97424: Low severity ubuntu/linux vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue concerns the AMDGPU RAS handling of cp_ecc_error_irq on the GFX v9 path. GFX v8 manages this IRQ locally and is stated to be unaffected; no other GFX generation has this IRQ.
Does this affect SR-IOV virtual functions?
No. Acquisition of cp_ecc_error_irq is skipped on SR-IOV virtual functions, and the corrected get and put paths use the same condition: not a VF and RAS functions registered.
When can the faulty cleanup path occur?
The relevant scenario includes suspend followed by driver unload without a resume. The fix adds an active flag so finalization does not release resources that the suspend path has already cleaned up.