Re: [PATCH v7 04/17] drm/msm: Synchronize set_sysprof on ctxlock

[sashiko-bot@kernel.org]

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 <robin.clark@oss.qualcomm.com>

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/20260729155609.20190-1-robin.clark@oss.qualcomm.com?part=4