Cloudanix VulnDB

CVE-2026-99149

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux graphics handling for AMD video cards can slowly leak memory when certain rare errors happen, eventually making the computer run poorly or crash.

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

What it actually does

Memory leak of GEM objects, VM root parent references, and MMU notifier registrations in the amdgpu driver when amdgpu_hmm_range_alloc fails in the userptr ioctl, bypassing the normal cleanup path.

Why it matters to the business

Repeated triggering can exhaust kernel memory on systems with AMD GPUs, leading to degraded performance, application failures, or system instability over time; urgency is low given the three-day publication age and absence from known exploitation lists.

How an attack unfolds

An attacker with local access crafts repeated calls to the affected ioctl that force the allocation failure, causing incremental resource leaks without triggering any other error-handling paths that would release the objects.

How to fix it

Update to a Linux kernel containing commit bbe739e407a542073ec1a7872b14843566b4919e or later; apply the backported fix that replaces the early return with a call to release_object when the range allocation fails.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the amdgpu_gem_userptr_ioctl function for the release_object call on the ENOMEM path from amdgpu_hmm_range_alloc; test by forcing allocation failures and verifying no net increase in GEM object counts.

Typical attack path

  1. Obtain local unprivileged access to a Linux system with an AMD GPU
  2. Invoke the amdgpu_gem_userptr_ioctl in a loop designed to trigger ENOMEM from amdgpu_hmm_range_alloc
  3. Accumulate leaked GEM objects and notifier registrations until memory pressure causes denial of service

How to detect it

Search kernel logs and memory accounting tools for repeated unexplained growth in GEM object counts or amdgpu-related notifier registrations on systems that perform userptr ioctls; correlate with application error paths that return ENOMEM.

What your security team should do

  • Prioritize kernel updates on any multi-user or exposed AMD GPU systems within standard patch windows
  • Monitor EPSS and KEV status for changes that would elevate priority
  • Review local workloads that perform frequent userptr operations for opportunities to reduce error-path exposure

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctl When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e)

Affected packages

Ecosystem Package Introduced Fixed