Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] Direct access to ctx->vm before VM lazy initialization in ioctl entry point. -- --- Patch [6]: [PATCH v6 06/16] drm/msm: Remove redundant SIZE_MAX check --- commit f2972a9fd99ad8ac26829ed01da6279a307ca6e7 Author: Rob Clark <[email protected]> drm/msm: Remove redundant SIZE_MAX check kmalloc() will already fail and return NULL if passed SIZE_MAX. > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index d55897c358371..62acee148bf2b 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -250,11 +250,6 @@ static int submit_lookup_cmds(struct msm_gem_submit > *submit, > > sz = array_size(submit_cmd.nr_relocs, > sizeof(struct drm_msm_gem_submit_reloc)); > - /* check for overflow: */ > - if (sz == SIZE_MAX) { > - ret = -ENOMEM; > - goto out; > - } > submit->cmd[i].relocs = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN); > if (!submit->cmd[i].relocs) { > ret = -ENOMEM; [Severity: Critical] This is a pre-existing issue, but looking at the same file in msm_ioctl_gem_submit(), there appears to be a direct access to ctx->vm before it is lazily initialized: drivers/gpu/drm/msm/msm_gem_submit.c:msm_ioctl_gem_submit() { ... if (to_msm_vm(ctx->vm)->unusable) return UERR(EPIPE, dev, "context is unusable"); ... } If a userspace process opens the DRM device and immediately calls the DRM_IOCTL_MSM_GEM_SUBMIT ioctl before calling any other ioctls that would initialize the VM (using the msm_context_vm() accessor), won't ctx->vm be NULL? Since to_msm_vm() is a container_of macro wrapping the first struct member, passing a NULL pointer yields a NULL pointer. Could dereferencing ->unusable here allow an unprivileged local user to trigger a kernel panic by calling this ioctl before the VM is initialized? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
