Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Direct access to uninitialized `ctx->vm` allows userspace to enable VM_BIND on hardware lacking per-process page tables. -- --- Patch [4]: [PATCH v7 04/17] drm/msm: Synchronize set_sysprof on ctxlock --- commit 80ad21c966f9ce52663d9bf52f28781c4e97e7e0 Author: Rob Clark <[email protected]> drm/msm: Synchronize set_sysprof on ctxlock A user that was perfmon_capable() could try to race setting SYSPROF param on multiple threads to trigger a reference leak. > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c > b/drivers/gpu/drm/msm/msm_submitqueue.c > index 8b5980d5a6a79..233c4f35ab121 100644 > --- a/drivers/gpu/drm/msm/msm_submitqueue.c > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c > @@ -9,6 +9,8 @@ > > int msm_context_set_sysprof(struct msm_context *ctx, struct msm_gpu *gpu, > int sysprof) > { > + guard(rwsem_write)(&ctx->ctxlock); > + > /* > * Since pm_runtime and sysprof_active are both refcounts, we > * call apply the new value first, and then unwind the previous [Severity: High] This isn't a bug introduced by this patch, but there is a pre-existing issue in adreno_set_param() when handling MSM_PARAM_EN_VM_BIND: drivers/gpu/drm/msm/adreno/adreno_gpu.c:adreno_set_param() { ... case MSM_PARAM_EN_VM_BIND: { guard(rwsem_read)(&ctx->ctxlock); /* We can only support VM_BIND with per-process pgtables: */ if (ctx->vm == gpu->vm) return UERR(EINVAL, drm, "requires per-process pgtables"); ... } Does this direct comparison against an uninitialized (NULL) ctx->vm fail to reject the VM_BIND enablement on GPUs without per-process page tables? If a userspace program calls the MSM_PARAM_EN_VM_BIND ioctl early, ctx->vm is NULL due to lazy initialization. The check if (ctx->vm == gpu->vm) in adreno_set_param() evaluates to false, bypassing the hardware capability check and incorrectly setting ctx->userspace_managed_vm = true. Later, when msm_context_vm() is called, msm_gpu_create_private_vm() returns the global gpu->vm because the hardware lacks support for private VMs. Userspace can then use the MSM_VM_BIND ioctl to map memory directly in the global GPU VM. Could a malicious userspace program exploit this to map and unmap arbitrary memory in the global GPU page tables, potentially overwriting mappings of other contexts and the kernel? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
