Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The `hpd_work` workqueue item is not cancelled during driver unbind, leading to a Use-After-Free if it executes after the device is removed. -- --- Patch [3]: [PATCH v4 03/10] drm/bridge: synopsys: dw-dp: Add follow-up bridge support --- commit de5a52e4cba577233c79861335c4c6a6060e2e33 Author: Sebastian Reichel <[email protected]> drm/bridge: synopsys: dw-dp: Add follow-up bridge support This commit adds support for using USB-C connectors with the DP altmode helper code on devicetree based platforms by attaching a follow-up bridge from the DP controller to the USB-C connector. > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > b/drivers/gpu/drm/bridge/synopsys/dw-dp.c > index aca6816febe67..0e8ecd73a0002 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c [ ... ] > @@ -2014,6 +2033,7 @@ void dw_dp_unbind(struct dw_dp *dp) > { > disable_irq(dp->irq); > phy_exit(dp->phy); > + drm_bridge_put(dp->next_bridge); > drm_dp_aux_unregister(&dp->aux); > drm_bridge_remove(&dp->bridge); > } [Severity: High] This is a pre-existing issue, but does dw_dp_unbind() leave pending work items that could cause a use-after-free? If an HPD interrupt fires right before or during driver unbind, it might schedule dp->hpd_work. The unbind function calls disable_irq(dp->irq), which synchronizes with the running handler but does not flush the workqueue. When the device is subsequently removed and the devm-managed dp structure is freed, could a delayed execution of dw_dp_hpd_work() dereference the freed dp pointer? Would it be appropriate to call cancel_work_sync(&dp->hpd_work) here during teardown to ensure the work item is safely cancelled? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260721-synopsys-dw-dp-improvements-v4-0-f0f4a4ede...@collabora.com?part=3
