Re: [PATCH v8 04/39] drm/connector: Add HDMI 2.0 scrambler infrastructure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing delayed work cancellation causes use-after-free and memory corruption on hot-unplug
--

commit 4ff004f5a0501b0ac5dedcf3dbce4ba7bc01c710
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

drm/connector: Add HDMI 2.0 scrambler infrastructure

This commit introduces connector-level infrastructure to support HDMI 2.0
scrambling. It includes various capability flags and a new delayed work item
(scdc_work) to monitor sink-side scrambling status.

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index c7ce6b7bd8b0e..deecfc582f093 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
[ ... ]
> @@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
>  	mutex_init(&connector->edid_override_mutex);
>  	mutex_init(&connector->hdmi.infoframes.lock);
>  	mutex_init(&connector->hdmi_audio.lock);
> +	INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
>  	connector->edid_blob_ptr = NULL;
>  	connector->epoch_counter = 0;
>  	connector->tile_blob_ptr = NULL;

[Severity: High]
Does this delayed work need to be explicitly cancelled during connector
teardown?

If a device is hot-unplugged or the driver is unbound while the display is
active and scrambling is enabled, the driver's atomic disable hooks might
skip calling drm_connector_hdmi_disable_scrambling() (e.g., if
drm_dev_enter() returns false on a disconnected device). 

If the connector is then torn down while scdc_work is still queued,
drm_connector_cleanup() will eventually be called, which zeros out the
connector structure:

drm_connector_cleanup()
    ...
    memset(connector, 0, sizeof(*connector));

Overwriting an actively queued delayed_work (and its internal timer_list)
with zeroes can corrupt the kernel's timer wheel and workqueue lists, leading
to a use-after-free or kernel panic when the timer fires.

Should there be a cancel_delayed_work_sync(&connector->hdmi.scdc_work) added
to drm_connector_cleanup() to prevent this?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com?part=4