Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] An off-by-one bounds check in `vc4_validate_shader_recs` allows an out-of-bounds read past the end of the `exec->bo` array, leading to a potential arbitrary pointer dereference. -- commit ded73237e9f7dd1d57c4b86e834979a9f46dac6e Author: WenTao Liang <[email protected]> fix: drm/vc4: vc4_cl_lookup_bos: fix NULL pointer dereference on drm_gem_objects_lookup failure When drm_gem_objects_lookup fails, it sets *objs_out to NULL, leaving exec->bo as NULL. The fail_put_bo error handler unconditionally iterates over exec->bo[i] without checking for NULL, causing a NULL pointer dereference. Add a NULL check for exec->bo before accessing its entries in the fail_put_bo error path. Cc: [email protected] Fixes: ba3f6db4afee ("drm/vc4: replace obj lookup steps with drm_gem_objects_lookup") > diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c > index e231c906709c1..b6cf24ca176cd 100644 > --- a/drivers/gpu/drm/vc4/vc4_gem.c > +++ b/drivers/gpu/drm/vc4/vc4_gem.c > @@ -723,10 +723,12 @@ vc4_cl_lookup_bos(struct drm_device *dev, > > fail_put_bo: > /* Release any reference to acquired objects. */ > - for (i = 0; i < exec->bo_count && exec->bo[i]; i++) > - drm_gem_object_put(exec->bo[i]); > + if (exec->bo) { > + for (i = 0; i < exec->bo_count && exec->bo[i]; i++) > + drm_gem_object_put(exec->bo[i]); > > - kvfree(exec->bo); > + kvfree(exec->bo); > + } > exec->bo = NULL; > return ret; > } [Severity: High] This is a pre-existing issue, but there appears to be an off-by-one bounds check when validating shader records that could allow an out-of-bounds read past the end of the exec->bo array. In drivers/gpu/drm/vc4/vc4_validate.c:validate_gl_shader_rec(): for (i = 0; i < shader_reloc_count; i++) { if (src_handles[i] > exec->bo_count) { DRM_DEBUG("Shader handle %d too big\n", src_handles[i]); return -EINVAL; } bo[i] = to_drm_gem_dma_obj(exec->bo[src_handles[i]]); if (!bo[i]) return -EINVAL; } If the handle index provided in src_handles[i] is exactly equal to exec->bo_count, the check passes, and exec->bo[exec->bo_count] is accessed. Could this result in an out-of-bounds read and a pointer dereference when this out-of-bounds value is cast to a drm_gem_dma_object? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
