Re: [PATCH 3/4] drm/bridge: display-connector: Support hardcoded EDID for VGA connectors

[Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>]

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, sashiko-bot@kernel.org 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 <laurent.pinchart+renesas@ideasonboard.com>
> 
> 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:
> 
> [ ... ]
>