CVE-2026-97496: drm/amdkfd: Fix OOB memory exposure in get_wave_state()
drm/amdkfd: Fix OOB memory exposure in getwavestate()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - 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
Who is exposed to this issue?
Systems using the Linux kernel AMDKFD driver are exposed where an attacker can reach the CRIU restore path through AMDKFD_IOC_RESTORE_PROCESS with H3. The issue concerns GPU queue state restored from attacker-controlled MQD fields.
What does an attacker need to exploit it?
The attacker needs control over the cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values in an MQD supplied on the CRIU-restore path. Those values can cause get_wave_state() to copy memory beyond the allocated control-stack buffer to user space.
What can be disclosed if exploitation succeeds?
The out-of-bounds copy can expose adjacent GTT or kernel memory. The described examples include other queues' MQDs, ring buffers, and KASLR pointers.
How does the fix prevent the exposure?
The fix clamps the MQD-provided stack size to the actual allocated buffer size, q->ctl_stack_size, and clamps the offset to that resulting size before arithmetic and copy_to_user(). This prevents reads beyond the allocated kernel buffer even when the MQD fields are attacker controlled.