Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Initialization order vulnerability: mutex and refcount initialized after object is globally visible. --
commit 43edb96a02a3e020c9ba63b15f602a74d5eb759f Author: Dmitry Baryshkov <[email protected]> drm/msm: serialise framebuffer pin state This commit introduces a mutex to serialize framebuffer pin states, resolving an issue where parallel prepare and cleanup callbacks could leave a plane programmed with a NULL base address. > diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c > --- a/drivers/gpu/drm/msm/msm_fb.c > +++ b/drivers/gpu/drm/msm/msm_fb.c [ ... ] > @@ -206,6 +227,7 @@ msm_framebuffer_init(struct drm_device *dev, const struct > drm_format_info *info, > } > > refcount_set(&msm_fb->dirtyfb, 1); > + mutex_init(&msm_fb->lock); [Severity: High] Since drm_framebuffer_init() is called just before this block and registers the object in the DRM core IDR, the framebuffer becomes immediately visible to userspace. If userspace guesses the assigned framebuffer ID and concurrently issues an atomic commit ioctl, could msm_framebuffer_prepare() execute and call mutex_lock(&msm_fb->lock) before mutex_init() finishes here? Could this race lead to memory corruption or deadlocks by clobbering the mutex state? Would it be safer to move the mutex initialization to before the drm_framebuffer_init() call? > > drm_dbg_state(dev, "create: FB ID: %d (%p)\n", fb->base.id, fb); > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
