Answer in brief
CVE-2026-68260 records a Unknown severity vulnerability in drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <1f1f2618e44b21a7d4eb30d3bbd7e015ffbbbadf || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <6253bb56bb2ebdf317d8b599ce737a2510cc2e17 || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <15f58d44c24477a6ebffa44ec05207b81cfa55d9 || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <17e2030f37600994440f875dc410615d5c66ee6d | 1f1f2618e44b21a7d4eb30d3bbd7e015ffbbbadf, 6253bb56bb2ebdf317d8b599ce737a2510cc2e17, 15f58d44c24477a6ebffa44ec05207b81cfa55d9, 17e2030f37600994440f875dc410615d5c66ee6d |
| Linux/Linuxgeneric | 6.8 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
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*().
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-68260 records a Unknown severity vulnerability in drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <1f1f2618e44b21a7d4eb30d3bbd7e015ffbbbadf || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <6253bb56bb2ebdf317d8b599ce737a2510cc2e17 || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <15f58d44c24477a6ebffa44ec05207b81cfa55d9 || >=ff5f643de0bf27874c4033cd57a0bd034b5c7d11 <17e2030f37600994440f875dc410615d5c66ee6d | 1f1f2618e44b21a7d4eb30d3bbd7e015ffbbbadf, 6253bb56bb2ebdf317d8b599ce737a2510cc2e17, 15f58d44c24477a6ebffa44ec05207b81cfa55d9, 17e2030f37600994440f875dc410615d5c66ee6d |
| Linux/Linuxgeneric | 6.8 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
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*().
Quoted source text, attributed separately from HOL analysis.