Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [High] drm: Missing drm_connector_cleanup() on atomic_create_state error path
--

commit 4c22451169f59e38b227f793ca15ca81195bb746
Author: Maxime Ripard <[email protected]>

drm/panel: Switch to drm_atomic_helper_connector_create_state

This commit replaces the deprecated reset hook with the 
atomic_create_state callback in the panel bridge connector implementation.

> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index c9f49e18890ad..55a1427c7a10a 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -70,9 +70,9 @@ panel_bridge_connector_helper_funcs = {
>  };
>  
>  static const struct drm_connector_funcs panel_bridge_connector_funcs = {
> -     .reset = drm_atomic_helper_connector_reset,
>       .fill_modes = drm_helper_probe_single_connector_modes,
>       .destroy = drm_connector_cleanup,
> +     .atomic_create_state = drm_atomic_helper_connector_create_state,

[Severity: High]
Does this change introduce a resource leak and a use-after-free in the error
path of panel_bridge_attach()?

By providing the atomic_create_state callback, panel_bridge_attach() will
now take a different branch when creating the state:

drivers/gpu/drm/drm_panel.c:panel_bridge_attach() {
    ...
        ret = drm_connector_init(bridge->dev, connector,
                                 &panel_bridge_connector_funcs,
                                 panel->connector_type);
    ...
                if (connector->funcs->atomic_create_state) {
                        struct drm_connector_state *conn_state;

                        conn_state = 
connector->funcs->atomic_create_state(connector);
                        if (IS_ERR(conn_state))
                                return PTR_ERR(conn_state);
    ...
}

If drm_atomic_helper_connector_create_state() fails, the function returns
the error directly.

Since the connector was successfully initialized by drm_connector_init()
earlier in the function, returning without calling drm_connector_cleanup()
appears to leak the connector's resources.

Could this also lead to a use-after-free when the DRM core later iterates
over dev->mode_config.connector_list containing a dangling pointer to this
uncleaned connector?

>       .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>       .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/20261014-drm-no-more-connector-reset-v1-0-586c9c026...@kernel.org?part=14

Reply via email to