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

[sashiko-bot@kernel.org]

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:

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705213542.28987-1-laurent.pinchart+renesas@ideasonboard.com?part=3