Re: [PATCH v3] drm/omap: Report HDMI hotplug events to the ASoC HDMI codec

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Manual driver unbinding via sysfs causes a data race and potential use-after-free because `omap_hdmi_audio_remove()` modifies `ha->audio_hpd` without `audio_lock` synchronization.
--

--- Patch [1]: [PATCH v3] drm/omap: Report HDMI hotplug events to the ASoC HDMI codec ---
commit c1e30662f9b8ea5c3f0c3b715617c1dbc5447474
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>

drm/omap: Report HDMI hotplug events to the ASoC HDMI codec

This commit adds an optional HPD callback to omap_hdmi_audio_pdata to
report HDMI cable hotplug events to ASoC. It updates the DRM HDMI bridge
to invoke this callback when the connector status changes, allowing user
space to detect audio availability.

> diff --git a/sound/soc/ti/omap-hdmi.c b/sound/soc/ti/omap-hdmi.c
> index e60f5b483fc57..90ce12a812468 100644
> --- a/sound/soc/ti/omap-hdmi.c
> +++ b/sound/soc/ti/omap-hdmi.c
[ ... ]
> @@ -371,28 +402,44 @@ static int omap_hdmi_audio_probe(struct platform_device *pdev)
[ ... ]
> +static void omap_hdmi_audio_remove(struct platform_device *pdev)
> +{
> +	struct omap_hdmi_audio_pdata *ha = pdev->dev.platform_data;
> +
> +	/*
> +	 * hdmi4_unbind() holds audio lock across platform_device_unregister(),
> +	 * so audio_hpd() cannot run concurrently with this callback.
> +	 */
> +	ha->audio_hpd = NULL;
> +}

[Severity: High]
Can a manual driver unbind via sysfs cause a data race and potential
use-after-free here?

While the comment notes that hdmi4_unbind() holds the audio_lock, an
administrator can unbind the driver directly via sysfs
(/sys/bus/platform/drivers/omap-hdmi-audio/unbind). If this happens,
omap_hdmi_audio_remove() will execute without holding the audio_lock.

Concurrently, if an HDMI hotplug event triggers hdmi_audio_hpd_notify(), it
could read a valid ha->audio_hpd pointer because the lock isn't held here.
Once omap_hdmi_audio_remove() completes, devres frees the driver data,
and the racing hdmi_audio_hpd_notify() would execute the callback using that
freed memory.

Should ha->audio_hpd be cleared under the protection of audio_lock, or is
there another mechanism to prevent this sysfs unbind race?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819171935.233946-1-ivo.g.dimitrov.75@gmail.com?part=1