Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Unsafe Lazy VM Access / Null Pointer Dereference in msm_ioctl_gem_submit. -- --- Patch [13]: [PATCH v7 13/17] drm/msm/gem: Validate lazy VM in GEM_NEW --- commit c70d69b1e94af5ce03e9eafbf80189affee59538 Author: Rob Clark <[email protected]> drm/msm/gem: Validate lazy VM in GEM_NEW This commit fixes a potential NULL pointer dereference when creating a NO_SHARE buffer object before any buffer objects are mapped. It ensures that the lazy VM is properly initialized and supported before proceeding. > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c > --- a/drivers/gpu/drm/msm/msm_gem.c > +++ b/drivers/gpu/drm/msm/msm_gem.c > @@ -1140,9 +1140,13 @@ int msm_gem_new_handle(struct drm_device *dev, struct > drm_file *file, [ ... ] > if (flags & MSM_BO_NO_SHARE) { > + struct msm_drm_private *priv = dev->dev_private; > struct msm_context *ctx = file->driver_priv; > struct drm_gpuvm *vm = msm_context_vm(dev, ctx); > > + if (!priv->gpu || !vm) > + return UERR(EINVAL, dev, "not supported with shared > VM"); > + > r_obj = drm_gpuvm_resv_obj(vm); > } [Severity: High] This is a pre-existing issue, but seeing how msm_context_vm() is used here to safely initialize the lazy VM, does a similar risk exist in msm_ioctl_gem_submit() where ctx->vm is accessed directly? If a user opens the DRM device node and immediately issues the MSM_GEM_SUBMIT ioctl before any other ioctls trigger VM creation, could this sequence cause a NULL pointer dereference? drivers/gpu/drm/msm/msm_gem_submit.c:msm_ioctl_gem_submit() { ... if (to_msm_vm(ctx->vm)->unusable) ... } Since base is at offset 0 in struct msm_gem_vm, to_msm_vm(NULL) evaluates to NULL. Would accessing the unusable flag immediately cause a dereference before msm_context_vm() is called to safely initialize the VM? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=13
