[PATCH v7 15/23] drm: bridge: dw_hdmi: Use generic CEC notifier helpers
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Mon May 18 11:53:00 PDT 2026
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free and memory leak due to drmm action lifetime mismatch with the connector
--
commit 7a3d2d4c9ae6107ffef88b867d73cc39dd7e8567
Author: Jonas Karlman <jonas at kwiboo.se>
drm: bridge: dw_hdmi: Use generic CEC notifier helpers
This commit replaces the open-coded CEC notifier handling with the generic
DRM HDMI CEC notifier helpers.
> The drmm release action for the generic CEC notifier should run just
> before dw_hdmi_connector_destroy(), closely matching the lifetime of
> the replaced CEC notifier and the connector.
Is this assumption accurate for all drivers using dw_hdmi?
When master drivers like sun4i or imx are unbound, drm_mode_config_cleanup()
is often called synchronously, which in turn calls dw_hdmi_connector_destroy().
If a userspace process holds the DRM file descriptor open, the drm_device
outlives the unbind. Doesn't this mean the drmm release action will run
much later than dw_hdmi_connector_destroy(), rather than just before it?
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 0e84dff724706..37406555af7bc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
[ ... ]
> @@ -2587,15 +2578,8 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>
> drm_connector_attach_encoder(connector, hdmi->bridge.encoder);
>
> - cec_fill_conn_info_from_drm(&conn_info, connector);
> -
> - notifier = cec_notifier_conn_register(hdmi->dev, NULL, &conn_info);
> - if (!notifier)
> - return -ENOMEM;
> -
> - hdmi->cec_notifier = notifier;
> -
> - return 0;
> + return drmm_connector_hdmi_cec_notifier_register(connector, NULL,
> + hdmi->dev);
> }
Could this cause a use-after-free when the drm_device is finally released?
Looking at dw_hdmi_connector_destroy(), it cleans up the connector state:
dw_hdmi_connector_destroy()
drm_connector_cleanup(connector)
...
memset(connector, 0, sizeof(*connector));
Since the connector is embedded in struct dw_hdmi which is managed by devres
and the bridge refcount, the memory will be freed when the platform device
unbind completes.
When the drmm action drm_connector_hdmi_cec_notifier_unregister() eventually
executes during drm_dev_release(), won't it attempt to dereference the
already freed connector pointer?
If the memory happens to still be accessible, won't it read the zeroed
connector->cec.data as a NULL pointer, silently leaking the CEC notifier?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518180206.2480119-1-jonas@kwiboo.se?part=15
More information about the linux-amlogic
mailing list