Re: [PATCH v3 2/4] drm/msm: Validate lazy VM is created in GEM_SUBMIT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Ineffective integer overflow protection during allocation size calculation in `submit_create` leads to potential heap buffer overflows.
--

commit 0bc0c946b740e56645786e074bd1e98b7bdd28a0
Author: Rob Clark <robin.clark@oss.qualcomm.com>
Subject: drm/msm: Validate lazy VM is created in GEM_SUBMIT

This commit fixes a potential NULL pointer dereference in the GEM_SUBMIT
ioctl. It ensures that the lazy VM is validated and created before any
buffer objects are mapped.

> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 26ea8a28be474..0dc983d155cd2 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -30,7 +30,7 @@
>   */
>  
>  static struct msm_gem_submit *submit_create(struct drm_device *dev,
> -		struct msm_gpu *gpu,
> +		struct msm_gpu *gpu, struct drm_gpuvm *vm,
>  		struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
>  		uint32_t nr_cmds, u64 drm_client_id)
>  {

[Severity: High]
This is a pre-existing issue, but does the overflow check in this function
work as intended?

In submit_create(), sz is calculated using struct_size() and assigned to a
uint64_t variable:

	sz = struct_size(submit, bos, nr_bos) +
			((u64)nr_cmds * sizeof(submit->cmd[0]));

	if (sz > SIZE_MAX)
		return ERR_PTR(-ENOMEM);

Since sz and SIZE_MAX share the same maximum width on 64-bit architectures,
can sz ever evaluate to strictly greater than SIZE_MAX?

If the struct_size() calculation saturates to SIZE_MAX upon overflow, the
subsequent addition of the command array size could wrap sz around to a small
positive value.

This would cause the check to evaluate to false and bypass the protection,
allocating a memory block that is too small for the requested elements and
allowing a potential heap buffer overflow if userspace provides extremely
large values for the number of buffer objects or commands.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260625222744.22254-1-robin.clark@oss.qualcomm.com?part=2