Re: [PATCH v5 3/4] drm/panel: Use managed helpers in assorted panels

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] drm/panel: Use-After-Free in panel-dsi-cm due to delayed drm_panel_remove
- [Low] drm/panel: khadas-ts050 compilation error due to undeclared variable
- [Low] drm/panel: tdo-tl070wsh30 compilation error due to undeclared variable
--

commit e1629ed943636f060c6cfc7188b70cdb9700480c
Author: Osama Abdelkader <osama.abdelkader@gmail.com>
Subject: drm/panel: Use managed helpers in assorted panels

This commit converts multiple panel drivers to use managed device helpers
for DRM panels and MIPI DSI attach operations. It removes the corresponding
manual detach and panel remove calls from the driver removal paths.

> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c b/drivers/gpu/drm/panel/panel-dsi-cm.c
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -559,16 +559,17 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>  	dsi->hs_rate = ddata->panel_data->max_hs_rate;
>  	dsi->lp_rate = ddata->panel_data->max_lp_rate;
>  
> -	drm_panel_add(&ddata->panel);
> +	r = devm_drm_panel_add(dev, &ddata->panel);
> +	if (r)
> +		goto err_sysfs;

[Severity: High]
Does using the managed version of drm_panel_add() here introduce a potential
use-after-free in dsicm_remove()?

By relying on devm, the execution of drm_panel_remove() is deferred to the
devres cleanup phase, which runs after the driver's .remove callback
(dsicm_remove) has already completed.

[ ... ]

> @@ -580,12 +581,13 @@ static int dsicm_probe(struct mipi_dsi_device *dsi)
>  static void dsicm_remove(struct mipi_dsi_device *dsi)
>  {
>  	struct panel_drv_data *ddata = mipi_dsi_get_drvdata(dsi);
> +	int ret;
>  
>  	dev_dbg(&dsi->dev, "remove\n");
>  
> -	mipi_dsi_detach(dsi);
> -
> -	drm_panel_remove(&ddata->panel);
> +	ret = mipi_dsi_detach(dsi);
> +	if (ret < 0)
> +		dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
>  
>  	sysfs_remove_group(&dsi->dev.kobj, &dsicm_attr_group);
>  

[Severity: High]
With the manual drm_panel_remove() gone, the panel remains registered with
the DRM core when dsicm_remove() subsequently cleans up the external
backlight reference just below this code block:

    if (ddata->extbldev)
        put_device(&ddata->extbldev->dev);

If a concurrent operation (such as a userspace DRM ioctl triggering a
display modeset) calls dsicm_disable() on the panel during the window
between dsicm_remove() returning and the devres cleanup executing, could
it attempt to use the freed extbldev pointer to disable the backlight?

[ ... ]

> diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> --- a/drivers/gpu/drm/panel/panel-khadas-ts050.c
> +++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> @@ -825,7 +825,9 @@ static int khadas_ts050_panel_add(struct khadas_ts050_panel *khadas_ts050)
>  	if (err)
>  		return err;
>  
> -	drm_panel_add(&khadas_ts050->base);
> +	ret = devm_drm_panel_add(dev, &khadas_ts050->base);
> +	if (ret)
> +		return ret;

[Severity: Low]
Will this cause a compilation error? It appears the variable "ret" is used
here, but looking at khadas_ts050_panel_add() in the source, only "err"
has been declared in this scope.

[ ... ]

> diff --git a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> --- a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> +++ b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> @@ -150,7 +150,9 @@ static int tdo_tl070wsh30_panel_add(struct tdo_tl070wsh30_panel *tdo_tl070wsh30)
>  	if (err)
>  		return err;
>  
> -	drm_panel_add(&tdo_tl070wsh30->base);
> +	ret = devm_drm_panel_add(dev, &tdo_tl070wsh30->base);
> +	if (ret)
> +		return ret;

[Severity: Low]
Does this also fail to compile for the same reason? The variable "ret" is
assigned and checked, but only "err" is declared in tdo_tl070wsh30_panel_add().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915145935.60397-1-osama.abdelkader@gmail.com?part=3