Re: [PATCH 27/37] drm/bridge: notify about detached bridges

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Dangling pointer: `bridge->encoder` is not cleared on detach, leading to potential Use-After-Free.
- [High] Premature teardown of atomic state, list linkages, and bridge resources before pipeline deconfiguration leads to UAF and list corruption.
--

commit 0a150cb9f7d5a0eebc9c0a446f33672c0a09a80b
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>

drm/bridge: notify about detached bridges

In preparation to support DRM bridge hotplug, let the drm_bridge code emit
an event when a bridge is detached, so that this event can trigger the
actions needed to deconfigure the pipeline and unregister the connector as
appropriate.

> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index e7e17bf4fdf9e..62413fff35fcb 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
[ ... ]
> @@ -638,6 +639,9 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>  		bridge->funcs->detach(bridge);
>  
>  	list_del_init(&bridge->chain_node);
> +
> +	drm_event_notifier_notify(DRM_BRIDGE_DETACHED, bridge);

The commit message mentions this event is meant to trigger actions to
deconfigure the pipeline. Since this event is emitted after tearing down the
bridge's atomic state, list linkages, and bridge resources, could this cause
issues when the listener attempts to safely disable the pipeline?

Specifically, earlier in this function:

	if (drm_bridge_is_atomic(bridge))
		drm_atomic_private_obj_fini(&bridge->base);

This destroys the bridge's modeset lock and frees its active atomic state. Any
concurrent atomic commit (like a userspace page flip) or a teardown commit
triggered by the listener might access freed memory or destroyed locks.

Additionally:

	list_del_init(&bridge->chain_node);

This locklessly modifies the encoder's bridge chain, which might corrupt the
list if a concurrent atomic commit is iterating the chain.

Finally, bridge->funcs->detach() has already executed, meaning the bridge has
released its internal resources, potentially making subsequent atomic disable
operations unsafe. Should the notification be emitted before the bridge state
and linkages are forcefully torn down?

> +
>  	bridge->dev = NULL;

Does this code also need to clear bridge->encoder?

Since bridges are refcounted, and listeners or other users might hold their
own references via drm_bridge_get(), the bridge can outlive the encoder.
If the encoder is destroyed (e.g., during driver unbind), could any access
to bridge->encoder by asynchronous event listeners or delayed cleanup
workers result in a use-after-free?

>  	drm_bridge_put(bridge);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com?part=27