Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
Cc: Frank.Li@kernel.org, dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org, robh@kernel.org, imx@lists.linux.dev,
	conor+dt@kernel.org
Subject: Re: [PATCH v3 02/11] drm/mxsfb/lcdif: simplify ep pointer management using __free
Date: Thu, 13 Aug 2026 23:24:17 +0000	[thread overview]
Message-ID: <20260813232418.247FA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260402-drm-lcdif-dbanc-v3-2-27cd247a0847@bootlin.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] devm_kzalloc allocated drm_encoder causes Use-After-Free on device unbind
--

--- Patch [2]: [PATCH v3 02/11] drm/mxsfb/lcdif: simplify ep pointer management using __free ---
commit f0c5403b21d20b71e67b52fb4f76773fe1e9a4f5
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>

drm/mxsfb/lcdif: simplify ep pointer management using __free

This patch simplifies endpoint device_node pointer management in lcdif_drv.c
by utilizing the __free(device_node) cleanup action to eliminate manual
of_node_put() calls on early return paths.

> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index 7719629487da5..8da8a265c05c8 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
[ ... ]
> @@ -65,23 +65,19 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
[ ... ]
>  		bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, of_ep.id);
> -		if (IS_ERR(bridge)) {
> -			of_node_put(ep);
> +		if (IS_ERR(bridge))
>  			return dev_err_probe(dev, PTR_ERR(bridge),
>  					     "Failed to get bridge for endpoint%u\n",
>  					     of_ep.id);
> -		}
>  
>  		encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);

[Severity: High]
This isn't a bug introduced by this patch, but could this devm_kzalloc()
cause a use-after-free on device unbind?

If a user opens the DRM device file, keeping the drm_device reference count
greater than 0, and the platform driver is concurrently unbound, the driver's
remove callback will return and the driver core will execute devm cleanup.

This cleanup frees the encoder. However, because the DRM device is still alive
due to the open file descriptor, the freed encoder remains linked in the
drm->mode_config lists.

When the user later closes the file and the DRM device refcount drops to 0,
will drm_mode_config_cleanup() iterate over the lists and access this freed
memory? Should this instead use a DRM-managed allocator to properly tie the
encoder's lifetime to the DRM device rather than the platform device?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260402-drm-lcdif-dbanc-v3-0-27cd247a0847@bootlin.com?part=2

  reply	other threads:[~2026-08-13 23:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02  9:25 [PATCH v3 00/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector Luca Ceresoli
2026-04-02  9:25 ` [PATCH v3 01/11] drm/mxsfb/lcdif: simplify remote pointer management using __free Luca Ceresoli
2026-04-02  9:25 ` [PATCH v3 02/11] drm/mxsfb/lcdif: simplify ep " Luca Ceresoli
2026-08-13 23:24   ` sashiko-bot [this message]
2026-04-02  9:25 ` [PATCH v3 03/11] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge Luca Ceresoli
2026-08-13 23:30   ` sashiko-bot
2026-04-02  9:25 ` [PATCH v3 04/11] drm/mxsfb/lcdif: move iteration-specific variables declaration inside loop " Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 05/11] drm/bridge: dw-hdmi: document the output_port field Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 06/11] drm/bridge: dw-hdmi: warn on unsupported attach combination Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 07/11] drm/bridge: dw-hdmi: move next_bridge lookup to attach time Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 08/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time Luca Ceresoli
2026-04-03  9:28   ` Liu Ying
2026-04-07 12:43     ` Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 09/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay Luca Ceresoli
2026-04-03  9:35   ` Liu Ying
2026-04-02  9:26 ` [PATCH v3 10/11] drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR Luca Ceresoli
2026-04-02  9:26 ` [PATCH v3 11/11] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector Luca Ceresoli

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=20260813232418.247FA1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --cc=luca.ceresoli@bootlin.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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