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 spam bot On Sun, 05 Jul 2026 21:44:52 +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 and missing asynchronous > cleanup during device removal when the driver is unbound. > -- > > commit 48f63e147d7554f73cd9df360e29fd0b0ddb5d8d > Author: Laurent Pinchart <[email protected]> > > drm/bridge: display-connector: Support hardcoded EDID for VGA connectors > > This commit adds support for parsing a hardcoded EDID blob from the device > tree > for VGA connectors when DDC signals are not connected. It also ensures that > specifying both a DDC bus and a hardcoded EDID returns an error during probe. > > > diff --git a/drivers/gpu/drm/bridge/display-connector.c > > b/drivers/gpu/drm/bridge/display-connector.c > > index eb3412ec30a07..225a8e987d086 100644 > > --- a/drivers/gpu/drm/bridge/display-connector.c > > +++ b/drivers/gpu/drm/bridge/display-connector.c > > [ ... ] > > > @@ -64,6 +67,9 @@ static enum drm_connector_status > > display_connector_detect(struct drm_bridge *bri > > if (conn->bridge.ddc && drm_probe_ddc(conn->bridge.ddc)) > > return connector_status_connected; > > > > + if (conn->edid) > > + return connector_status_connected; > > + > > [Severity: High] > This isn't a bug introduced by this patch, but does device removal have a > use-after-free vulnerability when the driver is unbound via sysfs? > > Looking at display_connector_detect() in > drivers/gpu/drm/bridge/display-connector.c, if the driver is bound and > attached > to a DRM encoder, and then unbound via sysfs: > > 1. display_connector_remove() calls drm_bridge_remove() but does not call > disable_irq() or cancel_work_sync(&conn->hpd_work). > 2. The bridge structure is kept alive because the DRM core still holds a > reference count. > 3. The driver core's devres_release_all() runs and frees conn->hpd_gpio and > the IRQ. > > If the DRM core then polls detect, it will execute display_connector_detect(): > > if (conn->hpd_gpio) { > if (gpiod_get_value_cansleep(conn->hpd_gpio)) > ... > > Will this dereference the devres-freed conn->hpd_gpio? > > Additionally, if the concurrent hpd_work executes, will it attempt to lock > bridge->hpd_mutex which was already destroyed by drm_bridge_remove()? > > > switch (conn->bridge.type) { > > case DRM_MODE_CONNECTOR_DVIA: > > [ ... ] >
