Re: [PATCH v9 05/61] drm/connector: Add HDMI 2.0 scrambler infrastructure

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The HDMI SCDC delayed work is cancelled in `drm_connector_cleanup()`, which executes at `drm_dev_release()` time for connectors initialized with `drmm_connector_init()` or `drmm_connector_hdmi_init()`. Since `drm_dev_release()` can be indefinitely delayed by userspace holding open file descriptors, the cancellation happens after the driver's `remove()`/`unbind()` function has completed and devres-managed resources (like I2C adapters or MMIO mappings) have been destroyed. If the delayed work fires during this window, it will attempt to access freed hardware resources, leading to a kernel panic or use-after-free. The cancellation must be performed synchronously during driver unbind, such as in `drm_connector_unregister()`, to guarantee the work does not outlive the hardware.
--

--- Patch [5]: [PATCH v9 05/61] drm/connector: Add HDMI 2.0 scrambler infrastructure ---
commit eea776d2943670e22f8c3877d36bf6a592c40119
Author: Cristian Ciocaltea <[email protected]>
Subject: drm/connector: Add HDMI 2.0 scrambler infrastructure

This commit adds connector-level infrastructure to support HDMI 2.0
scrambling. It introduces new callbacks, state flags, and a delayed work
item (scdc_work) to monitor and retry sink-side scrambling setup.

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 72b6304348028..96cca0ca64bd9 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
[ ... ]
> @@ -914,6 +932,9 @@ void drm_connector_cleanup(struct drm_connector *connector)
>  		    DRM_CONNECTOR_REGISTERED))
>  		drm_connector_unregister(connector);
>  
> +	if (connector->hdmi.scdc_work_initialized)
> +		cancel_delayed_work_sync(&connector->hdmi.scdc_work);

[Severity: High]
Since drmm_connector_hdmi_init() uses drmm, drm_connector_cleanup() will
execute at drm_dev_release() time. If userspace holds an open file
descriptor, drm_dev_release() can be indefinitely delayed after the
driver's remove() or unbind() function has completed.

If the device is unbound (e.g., via sysfs or physical hot-unplug) and
devres-managed resources like I2C adapters or MMIO mappings are destroyed,
could scdc_work fire during this window and attempt to access freed
hardware resources, leading to a use-after-free or kernel panic?

Should this cancellation be performed synchronously during driver unbind,
such as in drm_connector_unregister(), to guarantee the work does not
outlive the hardware?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5