Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Race condition during driver removal allows the HPD interrupt to re-arm a deleted timer, causing a Use-After-Free. -- --- Patch [6]: [PATCH v2 06/11] drm/mediatek: mtk_dp: Use PHY API for PHY power sequences --- commit 7b2bea0e460b138dc02e659a05248e8bd5c96d86 Author: AngeloGioacchino Del Regno <[email protected]> drm/mediatek: mtk_dp: Use PHY API for PHY power sequences The PHY driver has gained support for .power_on() and .power_off() callbacks. This commit updates the driver to use the API provided phy_power_on() and phy_power_off() functions instead of writing into PHY registers from this driver. > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c > b/drivers/gpu/drm/mediatek/mtk_dp.c > index 5c73572d153b5..b4cb1996a3314 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dp.c > +++ b/drivers/gpu/drm/mediatek/mtk_dp.c [ ... ] [Severity: High] This isn't a bug introduced by this patch, but is there a race condition during driver removal that could lead to a Use-After-Free? In mtk_dp_remove(), the driver deletes the debounce_timer but does not disable the device-managed hardware IRQ: drivers/gpu/drm/mediatek/mtk_dp.c:mtk_dp_remove() { ... if (mtk_dp->data->bridge_type != DRM_MODE_CONNECTOR_eDP) timer_delete_sync(&mtk_dp->debounce_timer); } If an HPD interrupt fires between mtk_dp_remove() returning and the devres cleanup phase that frees the IRQ, the interrupt handler executes and can re-arm the timer: drivers/gpu/drm/mediatek/mtk_dp.c:mtk_dp_hpd_event_thread() { ... if (status & MTK_DP_THREAD_CABLE_STATE_CHG) { ... if (!mtk_dp->train_info.cable_plugged_in) { ... mod_timer(&mtk_dp->debounce_timer, jiffies + msecs_to_jiffies(100) - 1); } ... } Shortly after, devres frees the mtk_dp structure. When this re-armed timer subsequently expires, could it access the freed mtk_dp memory and cause memory corruption? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
