All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh Ojha" <mukesh.ojha@oss.qualcomm.com>
Cc: linux-sunxi@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/11] drm: pl111: Use devm_of_reserved_mem_device_init()
Date: Wed, 02 Sep 2026 20:33:12 +0000	[thread overview]
Message-ID: <20260902203312.E17AE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902201640.2024648-4-mukesh.ojha@oss.qualcomm.com>

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

Pre-existing issues:
- [High] Pre-existing use-after-free and memory corruption risks due to tying resource lifetimes (`priv` structure and reserved memory) to `devres` (driver unbind) while the `drm_device` can outlive the unbind.
- [High] The `drm_panel_bridge` allocated via `drm_panel_bridge_add_typed()` in `pl111_modeset_init()` is leaked if `drm_dev_register()` fails.
- [High] When `INTEGRATOR_CLCD_CM` is matched, `pl111_versatile_init()` overwrites `np` without dropping the original reference. If the second match fails, probe incorrectly fails.
--

commit 76a1e18802677a9e3db4c051729d253910d2a13c
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

drm: pl111: Use devm_of_reserved_mem_device_init()

This patch converts the driver to use devm_of_reserved_mem_device_init,
allowing the reserved memory region to be released automatically on
probe failure or device removal. It removes the explicit cleanup calls.

> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
> index 8ec659b3c08eb..a07b17261961c 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -255,7 +255,7 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>  	drm->dev_private = priv;
>  	priv->variant = variant;
>  
> -	ret = of_reserved_mem_device_init(dev);
> +	ret = devm_of_reserved_mem_device_init(dev);

[Severity: High]
This is a pre-existing issue, but does tying resource lifetimes to devres
here expose a use-after-free risk?

The priv structure is allocated via devm_kzalloc() and the reserved
memory is now managed via devres, tying their lifetimes to the driver
unbind lifecycle. However, the drm_device is allocated without devres via
drm_dev_alloc() and tied to a refcount.

If a local user holds an open DRM file descriptor (like /dev/dri/card0)
and the driver is unbound via sysfs, devres will free priv and the reserved
memory while the DRM device persists. Because pl111_amba_remove() calls
drm_dev_unregister() instead of drm_dev_unplug(), the device is not
marked as unplugged and subsequent ioctls are not blocked.

An ioctl like DRM_IOCTL_PRIME_FD_TO_HANDLE will call
pl111_gem_import_sg_table(), which accesses dev->dev_private (priv),
potentially causing a use-after-free. Should the driver be migrated to
drm_dev_unplug() and devm_drm_dev_alloc() to prevent this?

[ ... ]

> @@ -314,7 +314,6 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>  
>  dev_put:
>  	drm_dev_put(drm);
> -	of_reserved_mem_device_release(dev);
>  
>  	return ret;
>  }

[Severity: High]
This is a pre-existing issue, but does this error path leak the panel
bridge?

During probe, a bridge is created by calling drm_panel_bridge_add_typed()
inside pl111_modeset_init(), which adds the bridge to the global DRM bridge
list with a reference count of 2.

If drm_dev_register() subsequently fails, the probe function jumps to
the dev_put label. The error path calls drm_dev_put(drm) but fails to
call drm_panel_bridge_remove(priv->bridge). When the panel device is
eventually unbound, its devres cleanup drops one reference on the bridge,
but the bridge is never removed from the global list, leaving a dangling
pointer. Does this need an explicit drm_panel_bridge_remove() call here?

Also, while reviewing the probe path, I noticed a potential node reference
issue in pl111_versatile_init() called earlier in this function:

drivers/gpu/drm/pl111/pl111_versatile.c:pl111_versatile_init() {
    ...
    np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
                                         &clcd_id);
    ...
    if (clcd_id == INTEGRATOR_CLCD_CM) {
        np = of_find_matching_node_and_match(NULL, impd1_clcd_of_match,
                                             &clcd_id);
}

[Severity: High]
This is a pre-existing issue, but does overwriting np without dropping the
original reference cause a memory leak?

For the INTEGRATOR_CLCD_CM type, a second call to
of_find_matching_node_and_match() is made, and its result overwrites np
without calling of_node_put() on the original node. If the IM-PD1 syscon
is not found, the second call returns NULL. The probe then calls
syscon_node_to_regmap(NULL), which fails and returns an error, preventing
the driver from probing successfully on valid standard Integrator AP
hardware. Should of_node_put() be called before reassigning np?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902201640.2024648-1-mukesh.ojha@oss.qualcomm.com?part=3

  reply	other threads:[~2026-09-02 20:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 20:16 [PATCH v2 0/11] drm: Use devm_of_reserved_mem_device_init() Mukesh Ojha
2026-09-02 20:16 ` [PATCH v2 1/11] drm: logicvc: " Mukesh Ojha
2026-09-02 20:30   ` sashiko-bot
2026-09-02 20:16 ` [PATCH v2 2/11] drm: hdlcd: " Mukesh Ojha
2026-09-02 20:16 ` [PATCH v2 3/11] drm: pl111: " Mukesh Ojha
2026-09-02 20:33   ` sashiko-bot [this message]
2026-09-02 20:16 ` [PATCH v2 4/11] drm: komeda: " Mukesh Ojha
2026-09-02 20:16 ` [PATCH v2 5/11] drm: malidp: " Mukesh Ojha
2026-09-02 20:35   ` sashiko-bot
2026-09-02 20:16 ` [PATCH v2 6/11] drm: ingenic: " Mukesh Ojha
2026-09-02 20:27   ` sashiko-bot
2026-09-02 20:16 ` [PATCH v2 7/11] drm: kmb: " Mukesh Ojha
2026-09-02 20:31   ` sashiko-bot
2026-09-02 20:16 ` [PATCH v2 8/11] drm: sun4i: " Mukesh Ojha
2026-09-02 20:16 ` [PATCH v2 9/11] drm: xlnx: zynqmp_dpsub: " Mukesh Ojha
2026-09-02 20:31   ` sashiko-bot
2026-09-02 20:55   ` Laurent Pinchart
2026-09-02 20:16 ` [PATCH v2 10/11] drm: aspeed: " Mukesh Ojha
2026-09-02 20:35   ` sashiko-bot
2026-09-02 20:16 ` [PATCH v2 11/11] drm: arcpgu: " Mukesh Ojha

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=20260902203312.E17AE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mukesh.ojha@oss.qualcomm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.