CVE-2026-99149 in Linux
Summary
by MITRE • 10/28/2026
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)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel driver for AMD GPU hardware, specifically the amdgpu subsystem within the Direct Rendering Manager (DRM), contains a resource management flaw in the user pointer ioctl implementation. This vulnerability arises from an improper error handling path when memory allocation fails during the initialization of a High Memory Management range. The function amdgpu_hmm_range_alloc is responsible for setting up necessary structures to manage user-space pointers mapped into GPU address space. When this allocation call returns failure due to insufficient kernel memory, indicated by an ENOMEM status code, the current control flow immediately exits with an error without executing the standard cleanup routines that are triggered in other error scenarios. This deviation from the expected resource lifecycle management results in several critical resources being left allocated and registered within the system but orphaned because no process holds a valid reference to them for proper deallocation.
The specific technical flaw involves the failure to release three distinct components of the GEM object infrastructure: the Graphics Execution Manager (GEM) object itself, the parent buffer object reference attached to the virtual memory root structure, and the MMU notifier registration that allows the kernel to track changes in user-space page tables. Because these resources are not freed upon allocation failure, they remain resident in kernel memory indefinitely until the associated process terminates or the system is rebooted. This constitutes a classic resource leak vulnerability where repeated exploitation through frequent ioctl calls can gradually consume available kernel memory pools. Over time, this accumulation of unreleased objects depletes system resources and can lead to broader instability within the operating environment.
From an operational impact perspective, this vulnerability primarily facilitates local denial-of-service attacks against systems running affected Linux kernels with AMD GPU drivers enabled. An unprivileged user-space application could intentionally trigger repeated memory allocation failures by exhausting available physical or swap space while simultaneously invoking the problematic ioctl interface. Each invocation would leave behind a small but non-trivial amount of kernel memory, leading to progressive resource exhaustion. While this does not directly allow for arbitrary code execution or privilege escalation in its current form, it undermines system reliability and availability. In environments where GPU resources are shared among multiple users or critical services, such leaks can degrade performance for all users by starving legitimate processes of necessary kernel memory allocations.
This issue aligns with CWE-401, which describes a missing release of memory after effective use, as well as CWE-772, referring to the lack of releasing resources after successful acquisition. The attack vector is classified under ATT&CK technique T1562.001, specifically Impair Defenses via Disable or Modify Tools, though in this context it manifests more accurately as resource exhaustion leading to service degradation rather than direct tool disabling. Mitigation strategies involve applying the upstream kernel patch that corrects the error handling logic by ensuring that release_object is called instead of user_pages_done when the range allocation fails. This ensures proper cleanup of all allocated structures regardless of which initialization step encounters an error. System administrators should prioritize updating to a patched version of the Linux kernel and amdgpu driver stack, particularly in multi-user or server environments where GPU resources are heavily utilized. Regular monitoring of kernel memory usage patterns can also help detect early signs of such leaks before they result in significant system instability.