Answer in brief
CVE-2026-97496 records a High severity (CVSS 7.1) vulnerability in drm/amdkfd: Fix OOB memory exposure in get_wave_state(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <d9183d974ddd5f09d029beaf359275ac20d4d5fe || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <ec646686613d8ab05b282d1463a7baa49fd6b83b || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <7ef144458f48d5589e36f1b3d83e83db2e5c5ba5 || >=0 <6.12.111 || >=0 <6.18.53 | d9183d974ddd5f09d029beaf359275ac20d4d5fe, ec646686613d8ab05b282d1463a7baa49fd6b83b, 7ef144458f48d5589e36f1b3d83e83db2e5c5ba5, 6.12.111, 6.18.53 |
Published upstream
Sep 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix OOB memory exposure in get_wave_state() The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values.
Quoted source text, attributed separately from HOL analysis.