All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: Frank.Li@kernel.org, robh@kernel.org,
	linux-hwmon@vger.kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	conor+dt@kernel.org, linux-i3c@lists.infradead.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v7 02/12] i3c: master: Use unified device property interface
Date: Tue, 28 Jul 2026 07:21:14 +0000	[thread overview]
Message-ID: <20260728072114.681291F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260728065955.809445-3-akhilrajeev@nvidia.com>

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

New issues:
- [High] Probing of I3C master controllers fails on ACPI platforms if they have child nodes.

Pre-existing issues:
- [High] Dangling pointer left in desc->dev upon device_register() failure leads to Use-After-Free and Double Free on teardown.
--

--- Patch [2]: [PATCH v7 02/12] i3c: master: Use unified device property interface ---
commit 67a3b30ddd40ca8910b28ac5cd83aad57174f7e8
Author: Akhil R <akhilrajeev@nvidia.com>

i3c: master: Use unified device property interface

Replace all OF-specific functions with unified device property functions
as a prerequisite to support both ACPI and device tree.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f1be38a640ca1..4b3d9628bc39b 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[ ... ]

> @@ -1928,7 +1930,7 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
>  			     desc->info.pid);
>  
>  		if (desc->boardinfo)
> -			desc->dev->dev.of_node = desc->boardinfo->of_node;
> +			device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
>  
>  		ret = device_register(&desc->dev->dev);
>  		if (ret) {

[Severity: High]
This is a pre-existing issue, but it appears desc->dev is left pointing to
a freed device if device_register() fails. When put_device() frees the
underlying struct i3c_device (via i3c_device_release()), desc->dev isn't
set to NULL.

Later, if i3c_master_unregister_i3c_devs() runs during teardown, could this
lead to a use-after-free and double-free?

i3c_master_unregister_i3c_devs() {
    ...
    i3c_bus_for_each_i3cdev(&master->bus, i3cdev) {
        if (!i3cdev->dev)
            continue;

        i3cdev->dev->desc = NULL;
        if (device_is_registered(&i3cdev->dev->dev))
            ...
        else
            put_device(&i3cdev->dev->dev);
    }
}

[ ... ]

> -static int of_i3c_master_add_dev(struct i3c_master_controller *master,
> -				 struct device_node *node)
> +static int i3c_master_add_dev(struct i3c_master_controller *master,
> +			      struct fwnode_handle *fwnode)
>  {
>  	u32 reg[3];
>  	int ret;
>  
>  	if (!master)
>  		return -EINVAL;
>  
> -	ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
> +	ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
>  	if (ret)
>  		return ret;

[Severity: High]
Since this function is now called for ACPI child nodes via
fwnode_populate_i3c_bus(), will this cause I3C master probe to fail on ACPI
systems?

ACPI nodes typically use _ADR or _CRS instead of a "reg" property. If "reg"
is missing, fwnode_property_read_u32_array() returns an error, which
propagates up and causes the entire master registration to abort.

Before this patch, the loop in of_populate_i3c_bus() was skipped completely
on ACPI systems because dev->of_node was NULL.

>  
>  	/*
>  	 * The manufacturer ID can't be 0. If that's the case, we're
>  	 * dealing with an I2C device.
>  	 */
>  	if (!reg[1])

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728065955.809445-1-akhilrajeev@nvidia.com?part=2

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: Frank.Li@kernel.org, robh@kernel.org,
	linux-hwmon@vger.kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	conor+dt@kernel.org, linux-i3c@lists.infradead.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v7 02/12] i3c: master: Use unified device property interface
Date: Tue, 28 Jul 2026 07:21:14 +0000	[thread overview]
Message-ID: <20260728072114.681291F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260728065955.809445-3-akhilrajeev@nvidia.com>

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

New issues:
- [High] Probing of I3C master controllers fails on ACPI platforms if they have child nodes.

Pre-existing issues:
- [High] Dangling pointer left in desc->dev upon device_register() failure leads to Use-After-Free and Double Free on teardown.
--

--- Patch [2]: [PATCH v7 02/12] i3c: master: Use unified device property interface ---
commit 67a3b30ddd40ca8910b28ac5cd83aad57174f7e8
Author: Akhil R <akhilrajeev@nvidia.com>

i3c: master: Use unified device property interface

Replace all OF-specific functions with unified device property functions
as a prerequisite to support both ACPI and device tree.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f1be38a640ca1..4b3d9628bc39b 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c

[ ... ]

> @@ -1928,7 +1930,7 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
>  			     desc->info.pid);
>  
>  		if (desc->boardinfo)
> -			desc->dev->dev.of_node = desc->boardinfo->of_node;
> +			device_set_node(&desc->dev->dev, desc->boardinfo->fwnode);
>  
>  		ret = device_register(&desc->dev->dev);
>  		if (ret) {

[Severity: High]
This is a pre-existing issue, but it appears desc->dev is left pointing to
a freed device if device_register() fails. When put_device() frees the
underlying struct i3c_device (via i3c_device_release()), desc->dev isn't
set to NULL.

Later, if i3c_master_unregister_i3c_devs() runs during teardown, could this
lead to a use-after-free and double-free?

i3c_master_unregister_i3c_devs() {
    ...
    i3c_bus_for_each_i3cdev(&master->bus, i3cdev) {
        if (!i3cdev->dev)
            continue;

        i3cdev->dev->desc = NULL;
        if (device_is_registered(&i3cdev->dev->dev))
            ...
        else
            put_device(&i3cdev->dev->dev);
    }
}

[ ... ]

> -static int of_i3c_master_add_dev(struct i3c_master_controller *master,
> -				 struct device_node *node)
> +static int i3c_master_add_dev(struct i3c_master_controller *master,
> +			      struct fwnode_handle *fwnode)
>  {
>  	u32 reg[3];
>  	int ret;
>  
>  	if (!master)
>  		return -EINVAL;
>  
> -	ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
> +	ret = fwnode_property_read_u32_array(fwnode, "reg", reg, ARRAY_SIZE(reg));
>  	if (ret)
>  		return ret;

[Severity: High]
Since this function is now called for ACPI child nodes via
fwnode_populate_i3c_bus(), will this cause I3C master probe to fail on ACPI
systems?

ACPI nodes typically use _ADR or _CRS instead of a "reg" property. If "reg"
is missing, fwnode_property_read_u32_array() returns an error, which
propagates up and causes the entire master registration to abort.

Before this patch, the loop in of_populate_i3c_bus() was skipped completely
on ACPI systems because dev->of_node was NULL.

>  
>  	/*
>  	 * The manufacturer ID can't be 0. If that's the case, we're
>  	 * dealing with an I2C device.
>  	 */
>  	if (!reg[1])

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728065955.809445-1-akhilrajeev@nvidia.com?part=2

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2026-07-28  7:21 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  6:59 [PATCH v7 00/12] Support ACPI and SETAASA device discovery Akhil R
2026-07-28  6:59 ` Akhil R
2026-07-28  6:59 ` [PATCH v7 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:08   ` sashiko-bot
2026-07-28  7:08     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 02/12] i3c: master: Use unified device property interface Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:21   ` sashiko-bot [this message]
2026-07-28  7:21     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 03/12] i3c: master: Support ACPI enumeration of child devices Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:18   ` sashiko-bot
2026-07-28  7:18     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 04/12] i3c: master: Add support for devices using SETAASA Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:22   ` sashiko-bot
2026-07-28  7:22     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 05/12] i3c: master: Add support for devices without PID Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:20   ` sashiko-bot
2026-07-28  7:20     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 06/12] i3c: master: match I3C device through DT and ACPI Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:20   ` sashiko-bot
2026-07-28  7:20     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:14   ` sashiko-bot
2026-07-28  7:14     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 08/12] i3c: dw-i3c-master: Add ACPI core clock frequency quirk Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:17   ` sashiko-bot
2026-07-28  7:17     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410 Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:19   ` sashiko-bot
2026-07-28  7:19     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 10/12] hwmon: spd5118: Remove 16-bit addressing Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:18   ` sashiko-bot
2026-07-28  7:18     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 11/12] hwmon: spd5118: Add I3C support Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:32   ` sashiko-bot
2026-07-28  7:32     ` sashiko-bot
2026-07-28  6:59 ` [PATCH v7 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon Akhil R
2026-07-28  6:59   ` Akhil R
2026-07-28  7:24   ` sashiko-bot
2026-07-28  7:24     ` sashiko-bot

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=20260728072114.681291F00A3E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=akhilrajeev@nvidia.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --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 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.