Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues: - [Critical] Use-After-Free (UAF) of the panel structure due to premature registration during probe - [High] Unbalanced runtime PM and resource leak in panel_simple_remove() - [High] TOCTOU race in panel_simple_shutdown() leading to lockless state corruption -- commit 887f69784ef5d71614e53c7181f7e8b567905759 Author: Myeonghun Pak <[email protected]> drm/panel: simple: Clean up resources on DSI attach failure This patch modifies panel_simple_dsi_probe() to call panel_simple_remove() when mipi_dsi_attach() fails. This cleans up common probe resources instead of just undoing panel registration. > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index c95964ba25a95..767068de68160 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -6552,11 +6552,8 @@ static int panel_simple_dsi_probe(struct > mipi_dsi_device *dsi) > dsi->lanes = desc->lanes; > > err = mipi_dsi_attach(dsi); > - if (err) { > - struct panel_simple *panel = mipi_dsi_get_drvdata(dsi); > - > - drm_panel_remove(&panel->base); > - } > + if (err) > + panel_simple_remove(&dsi->dev); [Severity: Critical] This isn't a bug introduced by this patch, but could this error path lead to a Use-After-Free (UAF) of the panel structure? When panel_simple_dsi_probe() calls panel_simple_probe(), the panel is allocated using devm_kzalloc() and registered globally via drm_panel_add(). At this point, it is visible to the system and a concurrent display driver can discover it via of_drm_find_panel() and store a pointer to it. If mipi_dsi_attach() fails here, panel_simple_remove() is called to unregister it, and the probe function returns an error. Returning an error triggers the driver core's devres cleanup, completely freeing the panel structure memory. However, the concurrent display driver might still hold a dangling pointer to this freed structure, resulting in a critical UAF upon subsequent access (e.g., calling drm_panel_prepare()). [Severity: High] This is a pre-existing issue, but does calling panel_simple_remove() here lead to an unbalanced runtime PM state and resource leak? Looking at panel_simple_remove(): static void panel_simple_remove(struct device *dev) { ... panel_simple_shutdown(dev); pm_runtime_dont_use_autosuspend(dev); pm_runtime_disable(dev); ... } panel_simple_shutdown() unprepares the panel, which calls pm_runtime_put_autosuspend() to schedule an asynchronous suspend, but leaves the device in the RPM_ACTIVE state. Then, pm_runtime_dont_use_autosuspend() and pm_runtime_disable() cancel the pending autosuspend and disable runtime PM entirely. Because a synchronous suspend (e.g., pm_runtime_suspend or pm_runtime_force_suspend) is omitted, the panel_simple_suspend() callback never executes. Will this leave the panel's regulator and GPIO permanently enabled, leading to a persistent hardware state and regulator enable count leak? [Severity: High] This is also a pre-existing issue, but is there a TOCTOU race in panel_simple_shutdown() (which is called by panel_simple_remove() above)? In panel_simple_shutdown(): static void panel_simple_shutdown(struct device *dev) { ... if (panel->base.enabled) drm_panel_disable(&panel->base); if (panel->base.prepared) drm_panel_unprepare(&panel->base); ... } These states are checked without holding any synchronization primitives (such as DRM modeset locks). If this runs concurrently with a DRM display controller performing a modeset (which independently calls drm_panel_disable), both threads may observe panel->base.enabled == true simultaneously. Could this lockless race lead to double-disabling of the panel, unbalanced regulator disables, and potential hardware state corruption? > > return err; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
