CVE-2026-68240

This CVE exposes a dangerous pattern in DRM gpusvm's page allocation and cleanup code: the dpagemap pointer is being used simultaneously as a resource handle AND as an implicit flag indicating whether device mappings were created. When __drm_gpusvm_unmap_pages() checks if dpagemap is non-NULL to decide whether to call device_unmap(), it assumes any non-NULL value means mappings exist — but the original code only assigned the pointer on the success path, meaning error paths left it NULL and cleanup was correctly skipped. The patch moves the assignment earlier to fix this, but that only patches the symptom. The deeper problem is that pointer NULL-ness is carrying semantic meaning beyond "initialized or not." This is a trap for future maintenance: someone adding a new error path or modifying the success path won't see in the type system or function signature that dpagemap assignment is load-bearing for cleanup. They'll see a pointer being stored and checked, and assume that's acceptable kernel style. Audit your codebase for this pattern: wherever a cleanup function infers work necessity from pointer NULL-ness rather than from explicit state, you have hidden coupling between code paths that looks independent but isn't. The fix isn't just moving assignments earlier — it's whether your cleanup function needs to receive explicit state (a boolean or enum) rather than inferring it. For gpusvm specifically, verify that any new device mapping types added to svm_pages maintain the same dpagemap contract, or better yet, introduce an explicit device_mappings_created flag that makes the dependency visible in the struct definition.

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