From: sashiko-bot@kernel.org
To: "Mukesh Ojha" <mukesh.ojha@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2 1/11] drm: logicvc: Use devm_of_reserved_mem_device_init()
Date: Wed, 02 Sep 2026 20:30:38 +0000 [thread overview]
Message-ID: <20260902203039.A074F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902201640.2024648-2-mukesh.ojha@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-after-free of layer structures (containing drm_plane) during driver cleanup due to incorrect devm vs. drmm initialization order.
- [High] Concurrent probe overwrites shared static global regmap_config, causing a data race.
--
commit 3a0c473b709e63281231182c727f9e5d25ce8b6f
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
drm: logicvc: Use devm_of_reserved_mem_device_init()
Switch to devm_of_reserved_mem_device_init() so the reserved memory region
is released automatically on probe failure or device unbind. Replace manual
cleanup labels with error_early.
> diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c
> index bbebf4fc7f51a..d6dbe52ff0a99 100644
> --- a/drivers/gpu/drm/logicvc/logicvc_drm.c
> +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c
[ ... ]
> @@ -327,14 +327,14 @@ static int logicvc_drm_probe(struct platform_device *pdev)
[ ... ]
> base = devm_ioremap_resource(dev, &res);
> if (IS_ERR(base)) {
> dev_err(dev, "Failed to map I/O base\n");
> ret = PTR_ERR(base);
> - goto error_reserved_mem;
> + goto error_early;
> }
>
> logicvc_drm_regmap_config.max_register = resource_size(&res) -
[Severity: High]
This isn't a bug introduced by this patch, but does this concurrent probe
overwrite the shared static global logicvc_drm_regmap_config?
Modifying a static global structure without locking can cause a data race if
multiple devices probe concurrently (e.g., if multiple IP cores are defined
in the device tree).
Depending on the race window, one device instance might be initialized with
the max_register value of another instance, leading to either restricted MMIO
access or out-of-bounds MMIO access.
> @@ -345,21 +345,21 @@ static int logicvc_drm_probe(struct platform_device *pdev)
[ ... ]
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> ret = -ENODEV;
> - goto error_reserved_mem;
> + goto error_early;
> }
>
> logicvc = devm_drm_dev_alloc(dev, &logicvc_drm_driver,
> struct logicvc_drm, drm_dev);
[Severity: High]
This is a pre-existing issue, but can this devm_drm_dev_alloc() call lead to
a use-after-free of layer structures during driver cleanup?
This call establishes the point in the devres stack where drm_dev_put() will
execute. Because logicvc_layer_init() allocates layer structures with
devm_kzalloc() after devm_drm_dev_alloc() executes:
drivers/gpu/drm/logicvc/logicvc_layer.c:logicvc_layer_init() {
...
layer = devm_kzalloc(dev, sizeof(*layer), GFP_KERNEL);
...
}
devres will execute in LIFO order on unbind. This means devm_kfree() frees
the layer memory before the DRM device's devres action calls drm_dev_put().
When the DRM device is finally destroyed, drmm actions execute (including
drm_mode_config_cleanup()), which iterates over registered planes and calls
their destroy hook (drm_plane_cleanup). Since the plane is embedded in the
already-freed layer struct, this causes a use-after-free.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902201640.2024648-1-mukesh.ojha@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-09-02 20:30 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 [this message]
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
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=20260902203039.A074F1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox