Cloudanix VulnDB

CVE-2026-98949

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A graphics driver bug on certain Linux systems can slowly leak memory when programs draw overlapping images, eventually making the computer unstable.

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

What it actually does

Reference count leak on GEM objects during GPU VA remap splits combined with incorrect vm_bo linking that triggers object mismatch checks in drm_gpuva_link.

Why it matters to the business

Memory exhaustion and driver warnings on systems using Imagination GPUs can lead to application crashes, reduced system stability, and unplanned downtime for graphics workloads.

How an attack unfolds

An attacker triggers repeated partial-overlap map operations that force pvr_vm_gpuva_remap to split existing mappings; each split leaks a GEM reference and mis-links objects, accumulating shmem until the system becomes unresponsive.

How to fix it

Update the Linux kernel to a version containing the fix for reference and vm_bo handling in pvr_vm_gpuva_remap; rebuild and reboot any affected distribution kernels.

How to confirm the fix worked

After patching, run the pvr_vm_map test suite and confirm absence of the 'shmem still held after close' critical message and the drm_WARN_ON in drm_gpuva_link.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with Imagination DRM driver loaded
  2. Open a render node and issue a sequence of vm_map ioctls that create overlapping GPU VA ranges
  3. Force splits via partial remaps that invoke pvr_vm_gpuva_remap
  4. Repeat to amplify the GEM reference leak and trigger drm_WARN_ON mismatches

How to detect it

Search kernel logs for 'CRITICAL: .* bytes of shmem still held after close' and 'WARNING: drivers/gpu/drm/drm_gpuvm.c' entries around drm_gpuva_link calls; inspect dmesg and journalctl for Imagination DRM stack traces.

What your security team should do

  • Prioritize kernel updates on any systems exposing Imagination GPUs to untrusted local users
  • Monitor for upcoming stable kernel releases containing the remap fix
  • Temporarily restrict access to /dev/dri/renderD* nodes if updates cannot be applied quickly

The record

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.

Affected packages

Ecosystem Package Introduced Fixed