From: sashiko-bot@kernel.org
To: "Sebastian Reichel" <sebastian.reichel@collabora.com>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v8 02/21] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback
Date: Fri, 31 Jul 2026 15:16:55 +0000 [thread overview]
Message-ID: <20260731151655.95F301F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260731-synopsys-dw-dp-improvements-v8-2-ac1e6a75782f@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Moving IRQ registration and hardware initialization to probe creates a window where an HPD interrupt causes a NULL pointer dereference on `dp->bridge.dev`.
Pre-existing issues:
- [Critical] Use-After-Free of the `dp` structure due to uncancelled `hpd_work` on driver removal.
--
--- Patch [2]: [PATCH v8 02/21] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback ---
commit 9de3c09754cbe88e934e9c5f4adf581795df6d41
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback
Currently the Synopsys DesignWare DP controller driver's bind function
requests lots of resources using device managed functions. These are
free'd on driver removal instead of at unbind time. Fix this discrepancy
by introducing a new probe helper function and moving over the whole
bind function.
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index 112a499113095..7f82495141711 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
[ ... ]
> @@ -2091,11 +2094,19 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> if (ret)
> return ERR_PTR(ret);
>
> - dp->irq = platform_get_irq(pdev, 0);
> - if (dp->irq < 0) {
> - ret = dp->irq;
> + bridge = &dp->bridge;
> + bridge->of_node = dev->of_node;
> + bridge->ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD;
> + bridge->type = DRM_MODE_CONNECTOR_DisplayPort;
> + bridge->ycbcr_420_allowed = true;
> +
> + ret = devm_drm_bridge_add(dev, bridge);
> + if (ret)
> return ERR_PTR(ret);
> - }
> +
> + dp->irq = platform_get_irq(pdev, 0);
> + if (dp->irq < 0)
> + return ERR_PTR(dp->irq);
>
> ret = devm_request_threaded_irq(dev, dp->irq, NULL, dw_dp_irq,
> IRQF_ONESHOT, dev_name(dev), dp);
[Severity: High]
Can this IRQ registration create a window for a NULL pointer dereference?
If a monitor is connected, the HPD interrupt can fire immediately after
devm_request_threaded_irq() completes in dw_dp_probe(). The interrupt handler
schedules dw_dp_hpd_work(), which directly dereferences dp->bridge.dev:
dw_dp_hpd_work()
drm_helper_hpd_irq_event(dp->bridge.dev);
Since the component bind hasn't run yet, drm_bridge_attach() hasn't been
called to assign dp->bridge.dev. Could this cause dw_dp_hpd_work() to
dereference a NULL pointer if an interrupt fires before the bridge is
attached?
> diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> index b23efb153c9e6..005938dc66c9f 100644
> --- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
[ ... ]
> @@ -128,12 +119,30 @@ static const struct component_ops dw_dp_rockchip_component_ops = {
> .unbind = dw_dp_rockchip_unbind,
> };
>
> -static int dw_dp_probe(struct platform_device *pdev)
> +static int dw_dp_rockchip_probe(struct platform_device *pdev)
> {
[ ... ]
> }
>
> -static void dw_dp_remove(struct platform_device *pdev)
> +static void dw_dp_rockchip_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &dw_dp_rockchip_component_ops);
> }
[Severity: Critical]
This is a pre-existing issue, but does this remove function leave a pending
work item that can cause a use-after-free?
Since there is no explicit cancel_work_sync(&dp->hpd_work) before the driver
exits dw_dp_rockchip_remove(), if an HPD interrupt fires right before removal,
the scheduled dw_dp_hpd_work() might remain on the system workqueue.
The devm cleanup runs after this function returns, freeing the IRQ and the dp
structure. If the work executes after dp is freed, it will access freed memory
when it runs container_of(work, struct dw_dp, hpd_work).
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260731-synopsys-dw-dp-improvements-v8-0-ac1e6a75782f@collabora.com?part=2
next prev parent reply other threads:[~2026-07-31 15:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 14:42 [PATCH v8 00/21] Synopsys DisplayPort Controller improvements for Rockchip platforms Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 01/21] drm/bridge: synopsys: dw-dp: Register DP AUX on bridge attach Sebastian Reichel
2026-07-31 15:03 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 02/21] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback Sebastian Reichel
2026-07-31 15:16 ` sashiko-bot [this message]
2026-07-31 14:42 ` [PATCH v8 03/21] drm/bridge: synopsys: dw-dp: Cancel pending HPD work Sebastian Reichel
2026-07-31 15:30 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 04/21] drm/bridge: synopsys: dw-dp: Document missing reset line deassert Sebastian Reichel
2026-07-31 15:38 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 05/21] drm/bridge: synopsys: dw-dp: Add missing mutex cleanups on module removal Sebastian Reichel
2026-07-31 15:50 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 06/21] drm/bridge: synopsys: dw-dp: Fix AUX transfer timeout race condition Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 07/21] drm/bridge: synopsys: dw-dp: Fix support for short I2C reads Sebastian Reichel
2026-07-31 16:16 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 08/21] drm/bridge: synopsys: dw-dp: Free output_fmts when none are valid Sebastian Reichel
2026-07-31 16:30 ` sashiko-bot
2026-07-31 14:42 ` [PATCH v8 09/21] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 10/21] drm/bridge: synopsys: dw-dp: Add follow-up bridge support Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 11/21] drm/bridge: Add out-of-band HPD notify handler Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 12/21] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 13/21] drm/rockchip: dw_dp: Implement out-of-band HPD handling Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 14/21] drm/bridge: synopsys: dw-dp: Add Runtime PM support Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 15/21] drm/rockchip: dw_dp: Add runtime " Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 16/21] drm/bridge: synopsys: dw-dp: Protect sdp_reg_bank from concurrent access Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 17/21] drm/bridge: synopsys: dw-dp: Drop useless reservation of first slot Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 18/21] drm/bridge: synopsys: dw-dp: Clear only enabled SDPs on atomic disable Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 19/21] drm/bridge: synopsys: dw-dp: Use regmap_set_bits in dw_dp_send_sdp Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 20/21] dt-bindings: display: rockchip: dw-dp: Fix sound DAI cells Sebastian Reichel
2026-07-31 14:42 ` [PATCH v8 21/21] drm/bridge: synopsys: dw-dp: Add audio support Sebastian Reichel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260731151655.95F301F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox