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 <[email protected]> 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/[email protected]?part=1
