Hello,

This is the friendly mail bot of Laurent Pinchart. You have sent him
what appears to be an e-mail generated by an LLM. In order to preserve
his mental health, the e-mail has been automatically ignored.

Thank you,

Laurent's mail bot

On Fri, 17 Jul 2026 19:01:28 +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
> to consider:
> 
> Pre-existing issues:
> - [High] Use-After-Free of devm-managed resources (hpd_gpio, hpd_irq) and 
> locking of destroyed mutexes during driver unbind.
> --
> 
> --- Patch [1]: [PATCH v2] drm/bridge: display-connector: Fix I2C adapter 
> resource leak ---
> commit 2b26eaff927cdb68a6ad11049169cdda7d66a1f8
> Author: Laurent Pinchart <[email protected]>
> 
> drm/bridge: display-connector: Fix I2C adapter resource leak
> 
> This commit moves the release of the I2C adapter to the bridge .destroy()
> handler to fix a reference leak when probe fails after getting the DDC
> adapter.
> 
> > diff --git a/drivers/gpu/drm/bridge/display-connector.c 
> > b/drivers/gpu/drm/bridge/display-connector.c
> > --- a/drivers/gpu/drm/bridge/display-connector.c
> > +++ b/drivers/gpu/drm/bridge/display-connector.c
> 
> [ ... ]
> 
> > @@ -439,9 +447,6 @@ static void display_connector_remove(struct 
> > platform_device *pdev)
> >             regulator_disable(conn->supply);
> >  
> >     drm_bridge_remove(&conn->bridge);
> 
> [Severity: High]
> This is a pre-existing issue, but does the bridge removal sequence leave
> devm-managed resources vulnerable to a use-after-free?
> 
> If the driver is unbound while the bridge is still attached to a DRM encoder,
> drm_bridge_remove() destroys bridge->hpd_mutex and moves the bridge to a
> lingering list. Because hpd_gpio and hpd_irq are devm-managed, devres will
> free them as soon as display_connector_remove() returns.
> 
> Could an incoming HPD interrupt fire right after drm_bridge_remove() and try
> to lock the destroyed bridge->hpd_mutex via drm_bridge_hpd_notify()?
> 
> Additionally, if the DRM core later calls display_connector_detect() or
> display_connector_hpd_disable() on the lingering bridge, would it result in a
> use-after-free when accessing the freed conn->hpd_gpio or conn->hpd_irq?
> 
> > -
> > -   if (!IS_ERR(conn->bridge.ddc))
> > -           i2c_put_adapter(conn->bridge.ddc);
> >  }
> >  
> >  static const struct of_device_id display_connector_match[] = {
> 

Reply via email to