Re: [PATCH v2 01/37] drm/adp: mipi: Add atomic bridge state handlers

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Repeatedly binding and unbinding the DSI panel driver causes a `devres` memory leak and leaves a stale, UAF-prone bridge in the global bridge list.
--

--- Patch [1]: [PATCH v2 01/37] drm/adp: mipi: Add atomic bridge state handlers ---
commit b7611e75cc83200ed90d21e397cf46cc1f10033a
Author: Maxime Ripard <mripard@kernel.org>

drm/adp: mipi: Add atomic bridge state handlers

The mipi bridge doesn't implement any enable or disable callbacks, but
is still missing the atomic state handlers. In order to remove the
legacy bridge callback support from the DRM bridge core, add them.

> diff --git a/drivers/gpu/drm/adp/adp-mipi.c b/drivers/gpu/drm/adp/adp-mipi.c
> index cba7d32150a98..232bb95394237 100644
> --- a/drivers/gpu/drm/adp/adp-mipi.c
> +++ b/drivers/gpu/drm/adp/adp-mipi.c
[ ... ]
> @@ -222,6 +223,9 @@ static int adp_dsi_bridge_attach(struct drm_bridge *bridge,
>  }
>  
>  static const struct drm_bridge_funcs adp_dsi_bridge_funcs = {
> +	.atomic_create_state = drm_atomic_helper_bridge_create_state,
> +	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> +	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>  	.attach	= adp_dsi_bridge_attach,
>  };
>  

[Severity: High]
This is a pre-existing issue, but while reviewing these bridge changes, I
noticed a resource management issue in adp_dsi_host_detach() in the same
file.

When a user unbinds the DSI panel driver, adp_dsi_host_detach() executes:

drivers/gpu/drm/adp/adp-mipi.c:adp_dsi_host_detach() {
    ...
    component_del(host->dev, &adp_dsi_component_ops);
    drm_bridge_remove(&adp->bridge);
    return 0;
}

However, during panel probe, adp_dsi_host_attach() allocates a panel bridge
using devm_drm_of_get_bridge(), tying the allocation to the host device
(adp->dsi.dev) rather than the panel device:

drivers/gpu/drm/adp/adp-mipi.c:adp_dsi_host_attach() {
    ...
    next = devm_drm_of_get_bridge(adp->dsi.dev, adp->dsi.dev->of_node, 1, 0);
    ...
}

Because the devres action is tied to the host device, unbinding the panel
does not free the bridge allocation. The drm_panel_bridge remains in the
global bridge list but points to the freed drm_panel.

If the panel is repeatedly unbound and bound, does this cause a devres memory
leak of bridge allocations?

Furthermore, if the DRM driver probes the bridge list later, could it
encounter this stale bridge and dereference the freed panel, leading to a
use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-drm-all-atomic-bridges-v2-0-21d03cbca446@kernel.org?part=1