CVE-2026-98949 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix reference and vm_bo handling in remap()
When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong.
- A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c):
CRITICAL: 33558528 bytes of shmem still held after close
- The parts still belong to the original object being split, but pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's vm_bo:
prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo) \___________link___________/ (mismatch: BO_A != BO_B)
drm_gpuva_link() catches the mismatch:
WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310 drm_WARN_ON(obj != vm_bo->obj) Call trace: drm_gpuva_link pvr_vm_gpuva_remap __drm_gpuvm_sm_map pvr_vm_map pvr_ioctl_vm_map
Link them to op->remap.unmap->va->vm_bo instead.
The locking of the GPUVA lists of the other objects touched by a split is not addressed here; it is handled by switching the GPUVM to immediate mode.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel driver for Imagination Technologies graphics hardware contains a critical logic error within the virtual memory object remapping functionality, specifically in the pvr_vm_gpuva_remap function. This vulnerability arises when an attempt is made to map a region that partially overlaps with an existing mapping. In such scenarios, the system correctly identifies the need to split the original mapping into previous and next segments to accommodate the new request without overwriting existing data. However, the implementation fails to manage resource lifecycles and object associations correctly during this splitting process, leading to both memory leaks and structural integrity violations within the kernel's graphics subsystem.
A primary consequence of this flaw is a significant reference count leak for Graphics Execution Manager objects. When the mapping is split into prev and next parts, the code erroneously increments the GEM reference counter for each new segment but fails to release these references when they are no longer needed or upon object closure. This results in shmem memory that remains held indefinitely after the associated file descriptor is closed. In testing scenarios such as pvr_vm_map.c, this manifests as tens of megabytes of unreleased shared memory per split operation. Over time, particularly under heavy graphical workloads involving frequent remapping operations, this unbounded accumulation of leaked references can exhaust system resources, leading to application crashes or broader system instability due to resource exhaustion.
Beyond the memory leak, the vulnerability introduces a severe object association mismatch that violates kernel integrity checks. The code incorrectly links the newly created virtual address ranges for the split segments to ctx->gpuvm_bo, which represents the new target buffer object of the remap operation. In reality, these split segments still logically belong to the original source buffer being modified. This discrepancy triggers a warning in drm_gpuva_link because the object pointer associated with the GPUVA does not match the expected vm_bo object. Such mismatches can corrupt internal data structures used by the DRM subsystem for tracking memory mappings and access permissions. If exploited or triggered repeatedly, this corruption could potentially lead to use-after-free conditions or invalid memory accesses when the kernel attempts to manage these mismatched entries during subsequent operations like unmapping or page fault handling.
The operational impact of this vulnerability extends beyond immediate resource leakage. The incorrect linking of GPU virtual address ranges can confuse the graphics driver's internal state machine, potentially causing rendering artifacts, application crashes, or hangs in graphical environments relying on Imagination hardware. Furthermore, the presence of these warnings indicates a breakdown in kernel consistency checks, which may mask more severe underlying issues if left unaddressed. The vulnerability is primarily triggered through user-space ioctl calls that request complex memory mappings involving partial overlaps, making it accessible to local users with appropriate privileges to interact with the graphics device interface.
Mitigation strategies involve applying the upstream Linux kernel patch that corrects these logic errors in the Imagination DRM driver. Developers and system administrators should ensure their systems are updated to a version of the kernel where pvr_vm_gpuva_remap properly handles reference counting by dropping unnecessary GEM references after splits and correctly links split segments to the appropriate original object rather than the target context buffer. Additionally, switching the GPUVM to immediate mode as noted in the fix helps address locking issues associated with other objects touched during a split, ensuring thread safety and preventing race conditions that could exacerbate these integrity violations. Regular monitoring of kernel logs for drm_gpuva_link warnings can serve as an indicator of whether affected systems are experiencing this flaw before patches are applied.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective lifetime, due to the failure to drop GEM references resulting in resource leaks. It also relates to CWE-823, use of objects with incorrect attributes, as the split virtual address ranges are incorrectly associated with a buffer object that does not match their actual ownership or origin. In terms of attack vectors and techniques, this falls under MITRE ATT&CK T1059, Command and Scripting Interpreter, specifically when considering how local users might leverage kernel driver flaws to escalate privileges or disrupt system stability through resource exhaustion or state corruption. The vulnerability highlights the importance of rigorous validation in graphics drivers where complex memory management operations are frequently invoked by user-space applications.