CVE-2026-68260

The CVE-2026-68260 patch locks pvr_vm_map(), but this treats a symptom. The real problem: drm_gpuvm exposes find() and map/unmap() as independent operations whose safety depends entirely on callers independently acquiring vm_ctx->lock—a lock that lives outside the core subsystem's API contract. The driver must know, entirely from external knowledge, that every find() call must be preceded by a lock the core API never demands. This is a classic violation of interface design: the contract should make correct usage natural and incorrect usage difficult. Instead, we have a subsystem where safe and unsafe paths look identical until a race window opens during specific interleaving. The null dereference at offset 0x10 into a GPUVA structure during find() indicates map/unmap tears down the data structure mid-iteration—a race that could have integrity consequences beyond kernel panic. The fix applied to pvr_vm_map() makes that call path safe, but the architecture remains unchanged. Any other driver calling map/unmap without acquiring vm_ctx->lock will hit the same race, and notably, their unsafe map/unmap can corrupt find() operations from drivers that ARE properly locking. The narrow race window explains why this went undetected—developers tested, found it worked, and shipped. The question is how many other DRM drivers using drm_gpuvm have not acquired vm_ctx->lock before map/unmap. The answer is likely "most of them, some haven't hit the window yet." Treat this less as a PowerVR bug and more as evidence that drm_gpuvm needs mandatory internal locking or a compiler-verifiable protocol.

Reviewed through automated stages and approved by a human before publication.