Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] MSM VM Lazy Initialization NULL Pointer Dereference -- --- Patch [5]: [PATCH v6 05/16] drm/msm: Move nr_cmds initialization --- commit 7351feaad392cc3ab54b31c35b1352065b9a2c8c Author: Rob Clark <[email protected]> drm/msm: Move nr_cmds initialization Previously if we entered an error path between these two points, we could leak the relocs tables due to submit->nr_cmds still being zero. Userspace could use this to trigger a memory leak. > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index 26ea8a28be474..d55897c358371 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c [ ... ] > @@ -719,8 +722,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > goto out; > } > > - submit->nr_cmds = args->nr_cmds; > - [Severity: Critical] This isn't a bug introduced by this patch, but can early validation in msm_ioctl_gem_submit() trigger a NULL pointer dereference? Because the MSM driver uses lazy initialization for virtual memory address spaces, ctx->vm will be NULL if this is the first operation on a newly created context. Unprivileged userspace applications could trigger this by opening the DRM device and calling the MSM_GEM_SUBMIT ioctl before any operation that initializes the VM. If ctx->vm is not yet initialized, direct access will crash when checking unusable status: msm_ioctl_gem_submit() { ... if (to_msm_vm(ctx->vm)->unusable) return UERR(EPIPE, dev, "context is unusable"); ... } Since base is at offset 0 in struct msm_gem_vm, to_msm_vm(NULL) returns NULL, leading to a dereference of NULL->unusable. Should this code path be updated to use msm_context_vm() to ensure the VM is fully created before checking its status? > idr_preload(GFP_KERNEL); > > spin_lock(&queue->idr_lock); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
