Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Missing `drm_panel_remove()` in the error path of `mipi_dsi_attach()` causes list corruption and use-after-free. -- commit 31f5775c1776d598f0568c50d1a4cecc265d2e88 Author: Albert Esteve <[email protected]> drm/panel/tdo-tl070wsh30: Use refcounted allocation in place of devm_kzalloc() This patch migrates the driver to use the devm_drm_panel_alloc API instead of devm_kzalloc. This adds refcounted allocation to the panel to prevent use-after-free bugs during unbind operations. Link: https://patch.msgid.link/[email protected] > diff --git a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > index 227f97f9b136f..13cfe252a838d 100644 > --- a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c > +++ b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c [ ... ] > @@ -183,10 +180,13 @@ static int tdo_tl070wsh30_panel_probe(struct > mipi_dsi_device *dsi) > dsi->format = MIPI_DSI_FMT_RGB888; > dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | > MIPI_DSI_MODE_LPM; > > - tdo_tl070wsh30 = devm_kzalloc(&dsi->dev, sizeof(*tdo_tl070wsh30), > - GFP_KERNEL); > - if (!tdo_tl070wsh30) > - return -ENOMEM; > + tdo_tl070wsh30 = devm_drm_panel_alloc(&dsi->dev, > + __typeof(*tdo_tl070wsh30), base, > + &tdo_tl070wsh30_panel_funcs, > + DRM_MODE_CONNECTOR_DSI); > + > + if (IS_ERR(tdo_tl070wsh30)) > + return PTR_ERR(tdo_tl070wsh30); > > mipi_dsi_set_drvdata(dsi, tdo_tl070wsh30); > tdo_tl070wsh30->link = dsi; > > err = tdo_tl070wsh30_panel_add(tdo_tl070wsh30); > if (err < 0) > return err; > > return mipi_dsi_attach(dsi); > } [Severity: High] This is a pre-existing issue, but does this error path lead to a use-after-free if mipi_dsi_attach fails? During tdo_tl070wsh30_panel_probe, the panel is added to the global list inside tdo_tl070wsh30_panel_add via drm_panel_add. If mipi_dsi_attach fails (which can happen due to probe deferral when the DSI host is not yet ready), the error is returned directly. The driver core will then unwind the devm resources, and the action registered by devm_drm_panel_alloc drops the kref and frees the panel memory. However, since drm_panel_remove is never called on this error path, the freed panel memory remains linked in the global panel_list. The next time the list is traversed, the kernel could dereference the freed memory, causing a crash. Should there be a call to drm_panel_remove to safely remove the panel from the list before returning the error? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
