CVE-2026-68260
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A locking mistake in graphics hardware drivers can let a logged-in user crash the computer or potentially gain extra privileges.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition between GPU VM map/unmap operations and internal find operations in drm_gpuvm allows concurrent access without vm_ctx->lock, resulting in NULL pointer dereference during drm_gpuva_find.
Why it matters to the business
Systems using Imagination PowerVR GPUs may experience kernel crashes or denial of service from local users; widespread Linux distributions with affected drivers increase operational risk until patched.
How an attack unfolds
A local attacker with low privileges issues rapid or concurrent VM unmap ioctls while internal find operations are active, triggering the unprotected drm_gpuva_find call that dereferences a NULL pointer and crashes the kernel.
How to fix it
Update the Linux kernel to a version containing the fix that acquires vm_ctx->lock before pvr_vm_map and related operations; rebuild and deploy the updated kernel package across all affected hosts.
How to confirm the fix worked
Verify the presence of the locking change in pvr_vm_map and pvr_vm_unmap functions in the running kernel source or binary; confirm no NULL dereference paths remain by reviewing drm_gpuva_find call sites under the vm_ctx lock.
Typical attack path
- Obtain local user access on a system with the vulnerable drm/imagination driver
- Open a DRM device file and allocate a GPU VM context
- Trigger concurrent or timed pvr_vm_unmap ioctls to race against internal find operations
- Cause drm_gpuva_find to access invalid memory and trigger kernel NULL dereference
How to detect it
Inspect kernel logs for oops or panic messages containing drm_gpuva_find, pvr_vm_unmap, or pvr_ioctl_vm_unmap; correlate with user-space processes issuing DRM ioctls on PowerVR devices.
What your security team should do
- Prioritize kernel updates on all systems exposing Imagination/PowerVR GPUs
- Restrict local user access to DRM device nodes via device permissions until patched
- Monitor for kernel oops reports referencing drm_gpuva_find or pvr_vm_unmap
The record
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [<ffffffff01e989d4>] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [<ffffffff01ed3a40>] pvr_vm_unmap+0x34/0x68 [powervr] [<ffffffff01ec69da>] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [<ffffffff8080ce0a>] drm_ioctl_kernel+0x8e/0xdc [<ffffffff8080d016>] drm_ioctl+0x1be/0x3e0 [<ffffffff802bec3e>] __riscv_sys_ioctl+0xba/0xc4 [<ffffffff80d858b2>] do_trap_ecall_u+0x23e/0x3f4 [<ffffffff80d92288>] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|