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: [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
