Re: [PATCH] drm/meson: clean up KMS polling on register failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-after-free of the `drm` pointer in the `free_drm` error path of `meson_drv_bind_master()`.
- [High] Memory leak of `devm_*` allocated resources during component bind failures or unbind operations.
--

commit 0a1b882dff3689e80c5546f7c0bf38c6930a1652
Author: Myeonghun Pak <mhun512@gmail.com>
drm/meson: clean up KMS polling on register failure

This commit fixes an issue in meson_drv_bind_master() where the KMS
polling helper is left running if drm_dev_register() fails. It introduces
a new uninstall_poll error path to call drm_kms_helper_poll_fini() before
freeing the IRQ.

> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 49ff9f1f16d32..e49de5df73867 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -352,12 +352,14 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
>  
>  	ret = drm_dev_register(drm, 0);
>  	if (ret)
> -		goto uninstall_irq;
> +		goto uninstall_poll;
>  
>  	drm_client_setup(drm, NULL);
>  
>  	return 0;
>  
> +uninstall_poll:
> +	drm_kms_helper_poll_fini(drm);
>  uninstall_irq:
>  	free_irq(priv->vsync_irq, drm);
>  exit_afbcd:

[Severity: High]
This isn't a bug introduced by this patch, but does the error unwinding path
have a use-after-free?

Looking further down in this function at the free_drm label:

free_drm:
	drm_dev_put(drm);

	meson_encoder_dsi_remove(priv);
	meson_encoder_hdmi_remove(priv);
	meson_encoder_cvbs_remove(priv);

	if (has_components)
		component_unbind_all(dev, drm);

Since drm_dev_put() drops the final reference and frees the drm structure,
won't component_unbind_all() trigger a use-after-free when unbind callbacks
dereference the freed pointer?

[Severity: High]
This is also a pre-existing issue, but are we leaking devm_* resources
during component bind failures or unbind operations?

Because devm allocations are scoped to the device probe lifecycle, they
are not implicitly released during bind failure paths or unbind calls.

Could this result in permanent memory leaks across retries if component
binding fails and is later retried?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524160657.17802-1-mhun512@gmail.com?part=1

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic