Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues: - [High] Use-after-free on error paths in probe due to un-cancelled delayed work. - [High] Resource leak of drm_bridge in probe error paths. - [High] Resource leak of DRM connector and CEC notifier if drm_bridge_attach fails. -- --- Patch [1]: [PATCH] drm/exynos: hdmi: take i2c adapter module reference --- commit 63541a71709f0db259d49c1fafb2342af0cef43e Author: Johan Hovold <[email protected]> drm/exynos: hdmi: take i2c adapter module reference This patch changes the i2c adapter retrieval to use of_get_i2c_adapter_by_node() instead of of_find_i2c_adapter_by_node() so it takes a module reference to prevent uninterruptible blocking during adapter deregistration. The removal path is updated to use i2c_put_adapter() instead of put_device(). > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 09b2cabb236f3..b971b7098a4d9 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c [ ... ] > @@ -2069,7 +2069,7 @@ static int hdmi_probe(struct platform_device *pdev) > if (hdata->regs_hdmiphy) > iounmap(hdata->regs_hdmiphy); > err_ddc: > - put_device(&hdata->ddc_adpt->dev); > + i2c_put_adapter(hdata->ddc_adpt); [Severity: High] This isn't a bug introduced by this patch, but does the error path here leave a pending delayed work item that could cause a use-after-free? In hdmi_probe(), hdata->hotplug_work is initialized and an IRQ handler is registered via devm_request_threaded_irq(). If the IRQ triggers during the remainder of the probe function, the handler will schedule the delayed work. If probe subsequently fails, devres automatically disables and frees the IRQ, and then frees hdata. However, because the error paths do not call cancel_delayed_work_sync(), the scheduled work could remain on the timer or workqueue and eventually execute, accessing the already freed hdata memory. [Severity: High] This isn't a bug introduced by this patch, but is there a resource leak of the drm_bridge in these error paths? Earlier in hdmi_probe(), hdmi_resources_init() acquires a bridge reference via of_drm_find_and_get_bridge() and stores it in hdata->bridge. If hdmi_probe() fails and takes this error path, it seems drm_bridge_put(hdata->bridge) is never called, leaking the reference and permanently pinning the bridge module. > > return ret; > } [Severity: High] This is a pre-existing issue, but can hdmi_create_connector() leak resources if drm_bridge_attach() fails? In hdmi_create_connector(), if drm_bridge_attach() fails, ret is set to an error code, but the function does not return immediately: drivers/gpu/drm/exynos/exynos_hdmi.c:hdmi_create_connector() { ... if (hdata->bridge) ret = drm_bridge_attach(encoder, hdata->bridge, NULL, 0); cec_fill_conn_info_from_drm(&conn_info, connector); hdata->notifier = cec_notifier_conn_register(hdata->dev, NULL, &conn_info); ... return ret; } If the CEC registration succeeds, the function returns the error code from drm_bridge_attach(). The caller observes the error and aborts, but since hdmi_connector_destroy() is never called, do the DRM connector and CEC notifier remain registered and leaked? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
