---
id: "CVE-2026-99106"
kind: "vulnerability"
aliases: ["CVE-2026-99106"]
title: "Linux amdgpu driver leaks memory when command submission fails"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["amd-gpu", "infrastructure", "linux-kernel", "self-hosted"]
not_affected_if: ["amdgpu-not-loaded", "no-amd-gpu"]
published_at: "2026-10-28T11:17:29+00:00"
first_seen_at: "2026-10-28T11:32:34+00:00"
updated_at: "2026-10-28T11:37:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99106", "first_seen_at": "2026-10-28T11:32:34+00:00"}]
---

# Linux amdgpu driver leaks memory when command submission fails

When an AMD GPU command submission fails after user page lookup, the kernel does not free the HMM range structures it allocated. Each failed submission leaks memory and a buffer object reference.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the running kernel version with `uname -r` and compare it to the fixed stable kernels listed in the NVD entry
- Check whether the amdgpu driver is loaded with `lsmod | grep amdgpu`

## Fix

- Update the Linux kernel to a stable release that includes the upstream commit c52a9542ed7cfd527feb938bd0accada2ac8d267 (fixed version unknown from sources)

## Timeline

- 2026-10-28T11:32:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99106

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: free the userptr ranges when a CS fails after parser_bos

amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of
the BO list and looks up the user pages. Those ranges are only freed when
amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks
them under the notifier lock. If amdgpu_cs_patch_jobs(),
amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of
amdgpu_cs_submit() fails, nothing frees them: neither
amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range.

Each such CS then leaks the range, its hmm_pfns array (8 bytes per page
of the userptr BO) and the BO reference the range holds. An IB on a ring
that patches the CS in place (e.g. VCN) with an unmapped va_start fails
in amdgpu_cs_patch_ibs() and takes this path.

Free the ranges on those error paths. Ranges amdgpu_cs_submit() already
dropped are NULL, so freeing them again is a no-op.

(cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267)

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_