Cloudanix VulnDB

CVE-2026-99106

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in AMD graphics drivers for Linux can slowly leak memory when certain graphics operations fail, potentially causing systems to run out of memory if triggered repeatedly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of HMM userptr ranges, hmm_pfns arrays, and BO references on specific amdgpu_cs error paths after successful parser_bos allocation.

Why it matters to the business

Repeated triggering of the leak can exhaust kernel memory on AMD GPU systems, degrading performance or causing denial of service over time; high ecosystem prevalence in Linux distributions amplifies exposure.

How an attack unfolds

An attacker crafts command submissions that succeed through amdgpu_cs_parser_bos but fail in later stages such as amdgpu_cs_patch_jobs, amdgpu_cs_vm_handling, or amdgpu_cs_sync_rings, repeatedly triggering the unfreed range paths to accumulate leaks without requiring special privileges beyond GPU access.

How to fix it

Apply the upstream fix that frees ranges on the identified error paths in amdgpu_cs_submit and related functions; upgrade to a patched Linux kernel version containing commit c52a9542ed7cfd527feb938bd0accada2ac8d267.

How to confirm the fix worked

Confirm kernel source includes the range-freeing logic on error paths after amdgpu_cs_parser_bos; monitor /proc/meminfo or slabinfo for sustained growth in amdgpu-related allocations under CS failure workloads.

Typical attack path

  1. Obtain access to a system with AMDGPU driver loaded
  2. Submit crafted CS workloads targeting VCN or similar rings that hit post-parser_bos failure paths
  3. Repeat submissions to accumulate leaked HMM ranges and associated memory
  4. Monitor for kernel memory exhaustion leading to system instability

How to detect it

Review kernel logs for repeated amdgpu CS failure messages around parser_bos success followed by patch or vm handling errors; correlate with increasing memory usage in HMM or amdgpu slab caches; no named threat actors or ransomware campaigns associated.

What your security team should do

  • Prioritize kernel upgrade within 7 days given public disclosure and one-day age
  • Audit workloads using AMD VCN or userptr BOs for error-prone CS patterns
  • Implement memory usage monitoring and alerting for amdgpu driver allocations
  • Test patched kernels in staging before broad deployment

The record

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)

Affected packages

Ecosystem Package Introduced Fixed