CVE-2026-99106: drm/amdgpu: free the userptr ranges when a CS fails after parser_bos
drm/amdgpu: free the userptr ranges when a CS fails after parserbos
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.59 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.13 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 7.2.13-1 - Upgrade
Upgrade
Linux kernel drm/amdgputo a version that resolves this vulnerability.Patch c52a9542ed7cfd527feb938bd0accada2ac8d267
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel amdgpu DRM driver are exposed when they process command submissions containing userptr buffer objects. The described failure case includes an IB on a ring that patches command submissions in place, such as VCN, with an unmapped va_start.
What does successful triggering cause?
Each affected command-submission failure leaks an HMM range, its hmm_pfns array, and a buffer-object reference held by the range. The hmm_pfns allocation consumes 8 bytes per page of the userptr buffer object, so repeated failures can accumulate memory and references.
What conditions are needed to reach the leak?
amdgpu_cs_parser_bos() must successfully allocate and populate ranges for userptr entries, followed by a failure in amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings(), or the early portion of amdgpu_cs_submit(). A specifically described path is failure in amdgpu_cs_patch_ibs() caused by an unmapped va_start on a ring that patches the submission in place.
How is the issue fixed?
The fix frees userptr ranges on the affected error paths. Ranges already released by amdgpu_cs_submit() are NULL, so attempting to free them again is a no-op.