Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: imx@lists.linux.dev, lee@kernel.org, Frank.Li@kernel.org,
	mfd@lists.linux.dev
Subject: Re: [PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()
Date: Tue, 21 Jul 2026 09:26:07 +0000	[thread overview]
Message-ID: <20260721092607.8AA2E1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-8-2dee93f42c54@oss.qualcomm.com>

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

Pre-existing issues:
- [High] Missing NULL check on `of_match_node()` result leads to NULL pointer dereference.
- [High] Premature freeing of parent controller's data in child driver's remove callback causes NULL pointer dereference.
- [High] Use-After-Free due to uncancelled work on the system workqueue.
--

--- Patch [8]: [PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode() ---
commit 1bfb7c41dded376cdac1bca23cdc026328648166
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()
    
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

> diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
> index 934c44c5bc1a9..bf077f47c9ddd 100644
> --- a/drivers/slimbus/qcom-ngd-ctrl.c
> +++ b/drivers/slimbus/qcom-ngd-ctrl.c
> @@ -1538,7 +1538,7 @@ static int of_qcom_slim_ngd_register(struct device *parent,
>  			kfree(ngd);
>  			return ret;
>  		}
> -		platform_device_set_of_node(ngd->pdev, node);
> +		platform_device_set_fwnode(ngd->pdev, of_fwnode_handle(node));
>  		ctrl->ngd = ngd;
>  
>  		ret = platform_device_add(ngd->pdev);

[Severity: High]
This isn't a bug introduced by this patch, but while looking at
of_qcom_slim_ngd_register(), I noticed that of_match_node() doesn't
have a NULL check:

drivers/slimbus/qcom-ngd-ctrl.c:of_qcom_slim_ngd_register() {
	...
	match = of_match_node(qcom_slim_ngd_dt_match, parent->of_node);
	data = match->data;
	...
}

Can this lead to a NULL pointer dereference if a user with root privileges
binds the driver via sysfs to a platform device that lacks an appropriate
of_node?

[Severity: High]
This is a pre-existing issue, but I noticed the parent controller's data
could be prematurely freed in the child driver's remove callback:

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_remove() {
	...
	kfree(ctrl->ngd);
	ctrl->ngd = NULL;
	...
}

If the child driver is unbound via sysfs, this frees ctrl->ngd. If the
parent driver is subsequently unbound, won't qcom_slim_ngd_unregister()
dereference the NULL ctrl->ngd pointer to delete the platform device?

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_unregister() {
	struct qcom_slim_ngd *ngd = ctrl->ngd;

	platform_device_del(ngd->pdev);
}

[Severity: High]
This is also a pre-existing issue, but could there be a use-after-free
if work is scheduled on the system workqueue during driver removal?

In qcom_slim_ngd_ctrl_remove(), the private workqueue is destroyed, but
cancel_work_sync(&ctrl->ngd_up_work) is omitted for the system workqueue:

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_ctrl_remove() {
	...
	destroy_workqueue(ctrl->mwq);
	...
}

If the scheduled work executes after devres frees the ctrl structure, won't
the worker dereference the freed memory?

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_up_worker() {
	...
	ctrl = container_of(work, struct qcom_slim_ngd_ctrl, ngd_up_work);
	...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=8

      reply	other threads:[~2026-07-21  9:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  9:24 [PATCH 0/8] driver core: prefer platform_device_set_fwnode() Bartosz Golaszewski
2026-07-20  9:24 ` [PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode() Bartosz Golaszewski
2026-07-21  9:25   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 2/8] i2c: pxa-pci: " Bartosz Golaszewski
2026-07-20  9:41   ` Wolfram Sang
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 3/8] iommu/fsl: " Bartosz Golaszewski
2026-07-20 12:58   ` Robin Murphy
2026-07-20 13:39     ` Bartosz Golaszewski
2026-07-20 14:34       ` Robin Murphy
2026-07-20 14:34   ` Frank Li
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 4/8] net: bcmgenet: " Bartosz Golaszewski
2026-07-20 14:38   ` Andrew Lunn
2026-07-20 16:57     ` Florian Fainelli
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 5/8] pmdomain: imx: " Bartosz Golaszewski
2026-07-20 14:34   ` Frank Li
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 6/8] mfd: tps6586: " Bartosz Golaszewski
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 7/8] net: mv643xx: " Bartosz Golaszewski
2026-07-20 14:43   ` Andrew Lunn
2026-07-20 16:01     ` Bartosz Golaszewski
2026-07-20 18:28       ` Andrew Lunn
2026-07-21  7:57         ` Bartosz Golaszewski
2026-07-21  9:26   ` sashiko-bot
2026-07-20  9:24 ` [PATCH 8/8] slimbus: qcom-ngd-ctrl: " Bartosz Golaszewski
2026-07-21  9:26   ` sashiko-bot [this message]

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=20260721092607.8AA2E1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=imx@lists.linux.dev \
    --cc=lee@kernel.org \
    --cc=mfd@lists.linux.dev \
    --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