CVE-2026-97424 drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq
A race condition in the AMD GPU RAS driver can cause a double-release of an IRQ, leading to a kernel crash and denial of service.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-97424?
CVE-2026-97424 is a vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq
cp_ecc_error_irq is acquired in amdgpu_gfx_ras_late_init() but released in gfx_v9_0_hw_fini(), so the put site has to query amdgpu_irq_enabled() because the get is skipped on SR-IOV VF.
ras_late_init / ras_fini have no suspend counterpart, so move the put to amdgpu_gfx_ras_suspend() / amdgpu_gfx_ras_fini() and add a matching ras_suspend callback that is invoked from amdgpu_ras_suspend() before disable_all_features(). 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 ras_fini so the suspend-then-unload-without-resume path falls into amdgpu_ras_block_late_fini_default() instead of double-releasing what ras_suspend already cleaned up.
Drop the cp_ecc_error_irq put from gfx_v9_0_hw_fini(). gfx_v8_0 manages cp_ecc_error_irq locally and is unaffected; no other GFX generation has this IRQ.
Which versions are affected by CVE-2026-97424?
How do I fix CVE-2026-97424?
Apply the vendor's patch.
Is CVE-2026-97424 being exploited?
There is no known exploitation of CVE-2026-97424 in the wild and no public exploit code.
Sources
Also known as AZL-103700, BELL-CVE-2026-97424, DEBIAN-CVE-2026-97424, GHSA-8j24-26wj-v3hq, UBUNTU-CVE-2026-97424.