From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: linux-i3c@lists.infradead.org, conor+dt@kernel.org,
robh@kernel.org, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v4 05/12] i3c: master: Add support for devices without PID
Date: Tue, 16 Jun 2026 10:17:38 +0000 [thread overview]
Message-ID: <20260616101738.CF6891F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260616095429.3947205-6-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The fallback logic added to `i3c_master_attach_boardinfo` for matching devices without a PID is completely unreachable dead code.
Pre-existing issues:
- [High] Dangling pointer in `i3c_master_register_new_i3c_devs()` error path leads to Use-After-Free and Double-Free.
--
commit 02ce08803703bc5626ea5224b66caedd628224e4
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: Add support for devices without PID
Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 557332d932576..bcc9c2d29c342 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -1963,8 +1963,17 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
> desc->dev->dev.type = &i3c_device_type;
> desc->dev->dev.bus = &i3c_bus_type;
> desc->dev->dev.release = i3c_device_release;
> - dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
> - desc->info.pid);
> +
> + /*
> + * For devices without PID (e.g., SETAASA devices), use
> + * static address for naming instead.
> + */
> + if (desc->info.pid)
> + dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
> + desc->info.pid);
> + else
> + dev_set_name(&desc->dev->dev, "%d-%02x", master->bus.id,
> + desc->info.static_addr);
>
> if (desc->boardinfo)
> device_set_node(&desc->dev->dev,
> fwnode_handle_get(desc->boardinfo->fwnode));
>
> ret = device_register(&desc->dev->dev);
> if (ret) {
> dev_err(&master->dev,
> "Failed to add I3C device (err = %d)\n", ret);
> put_device(&desc->dev->dev);
> }
[Severity: High]
This is a pre-existing issue, but does this error path leave a dangling
pointer that can cause memory corruption?
If device_register() fails, put_device() drops the reference and frees
desc->dev. However, desc->dev is not set to NULL.
When the I3C master later unregisters, i3c_master_unregister_i3c_devs()
iterates through the bus devices. Since the pointer is left dangling, it
passes the if (!i3cdev->dev) check, leading to write-after-free when
setting i3cdev->dev->desc = NULL, followed by a double-free when calling
put_device() again.
Should desc->dev be set to NULL after calling put_device() here?
[ ... ]
> @@ -2357,8 +2366,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
> struct i3c_dev_boardinfo *i3cboardinfo;
>
> list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
> - if (i3cdev->info.pid != i3cboardinfo->pid)
> - continue;
> + /*
> + * For devices without PID (e.g., SETAASA devices), match by
> + * static address. For devices with PID, match by PID.
> + */
> + if (i3cboardinfo->pid) {
> + if (i3cdev->info.pid != i3cboardinfo->pid)
> + continue;
> + } else {
> + if (!i3cboardinfo->static_addr ||
> + i3cdev->info.static_addr != i3cboardinfo->static_addr)
> + continue;
> + }
[Severity: Low]
Is this else block reachable?
Looking at i3c_master_add_i3c_boardinfo(), it requires a valid PID for all
non-SETAASA devices. Since SETAASA devices bypass
i3c_master_attach_boardinfo() entirely as they are attached early via
i3c_master_early_i3c_dev_add(), wouldn't i3cboardinfo->pid be strictly
non-zero for any device reaching this function?
Additionally, for dynamically discovered devices, wouldn't
i3cdev->info.static_addr be 0 prior to this call, causing
i3cdev->info.static_addr != i3cboardinfo->static_addr to always be true
anyway?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=5
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: linux-i3c@lists.infradead.org, conor+dt@kernel.org,
robh@kernel.org, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v4 05/12] i3c: master: Add support for devices without PID
Date: Tue, 16 Jun 2026 10:17:38 +0000 [thread overview]
Message-ID: <20260616101738.CF6891F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260616095429.3947205-6-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The fallback logic added to `i3c_master_attach_boardinfo` for matching devices without a PID is completely unreachable dead code.
Pre-existing issues:
- [High] Dangling pointer in `i3c_master_register_new_i3c_devs()` error path leads to Use-After-Free and Double-Free.
--
commit 02ce08803703bc5626ea5224b66caedd628224e4
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: master: Add support for devices without PID
Devices using SETAASA for address assignment are not required to have
a 48-bit PID according to the I3C specification. Allow such devices to
register and use the static address where PID was required.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 557332d932576..bcc9c2d29c342 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -1963,8 +1963,17 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
> desc->dev->dev.type = &i3c_device_type;
> desc->dev->dev.bus = &i3c_bus_type;
> desc->dev->dev.release = i3c_device_release;
> - dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
> - desc->info.pid);
> +
> + /*
> + * For devices without PID (e.g., SETAASA devices), use
> + * static address for naming instead.
> + */
> + if (desc->info.pid)
> + dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id,
> + desc->info.pid);
> + else
> + dev_set_name(&desc->dev->dev, "%d-%02x", master->bus.id,
> + desc->info.static_addr);
>
> if (desc->boardinfo)
> device_set_node(&desc->dev->dev,
> fwnode_handle_get(desc->boardinfo->fwnode));
>
> ret = device_register(&desc->dev->dev);
> if (ret) {
> dev_err(&master->dev,
> "Failed to add I3C device (err = %d)\n", ret);
> put_device(&desc->dev->dev);
> }
[Severity: High]
This is a pre-existing issue, but does this error path leave a dangling
pointer that can cause memory corruption?
If device_register() fails, put_device() drops the reference and frees
desc->dev. However, desc->dev is not set to NULL.
When the I3C master later unregisters, i3c_master_unregister_i3c_devs()
iterates through the bus devices. Since the pointer is left dangling, it
passes the if (!i3cdev->dev) check, leading to write-after-free when
setting i3cdev->dev->desc = NULL, followed by a double-free when calling
put_device() again.
Should desc->dev be set to NULL after calling put_device() here?
[ ... ]
> @@ -2357,8 +2366,18 @@ static void i3c_master_attach_boardinfo(struct i3c_dev_desc *i3cdev)
> struct i3c_dev_boardinfo *i3cboardinfo;
>
> list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
> - if (i3cdev->info.pid != i3cboardinfo->pid)
> - continue;
> + /*
> + * For devices without PID (e.g., SETAASA devices), match by
> + * static address. For devices with PID, match by PID.
> + */
> + if (i3cboardinfo->pid) {
> + if (i3cdev->info.pid != i3cboardinfo->pid)
> + continue;
> + } else {
> + if (!i3cboardinfo->static_addr ||
> + i3cdev->info.static_addr != i3cboardinfo->static_addr)
> + continue;
> + }
[Severity: Low]
Is this else block reachable?
Looking at i3c_master_add_i3c_boardinfo(), it requires a valid PID for all
non-SETAASA devices. Since SETAASA devices bypass
i3c_master_attach_boardinfo() entirely as they are attached early via
i3c_master_early_i3c_dev_add(), wouldn't i3cboardinfo->pid be strictly
non-zero for any device reaching this function?
Additionally, for dynamically discovered devices, wouldn't
i3cdev->info.static_addr be 0 prior to this call, causing
i3cdev->info.static_addr != i3cboardinfo->static_addr to always be true
anyway?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=5
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-06-16 10:17 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 9:54 [PATCH v4 00/12] Support ACPI and SETAASA device discovery Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 9:54 ` [PATCH v4 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:04 ` sashiko-bot
2026-06-16 10:04 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 02/12] i3c: master: Use unified device property interface Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:17 ` sashiko-bot
2026-06-16 10:17 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 03/12] i3c: master: Support ACPI enumeration of child devices Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:15 ` sashiko-bot
2026-06-16 10:15 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 04/12] i3c: master: Add support for devices using SETAASA Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:19 ` sashiko-bot
2026-06-16 10:19 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 05/12] i3c: master: Add support for devices without PID Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:17 ` sashiko-bot [this message]
2026-06-16 10:17 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 06/12] i3c: master: match I3C device through DT and ACPI Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:12 ` sashiko-bot
2026-06-16 10:12 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:13 ` sashiko-bot
2026-06-16 10:13 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 08/12] i3c: dw-i3c-master: Add a quirk to skip clock and reset Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:14 ` sashiko-bot
2026-06-16 10:14 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 09/12] i3c: dw-i3c-master: Add ACPI ID for Tegra410 Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:09 ` sashiko-bot
2026-06-16 10:09 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 10/12] hwmon: spd5118: Remove 16-bit addressing Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:09 ` sashiko-bot
2026-06-16 10:09 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 11/12] hwmon: spd5118: Add I3C support Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:30 ` sashiko-bot
2026-06-16 10:30 ` sashiko-bot
2026-06-16 9:54 ` [PATCH v4 12/12] arm64: defconfig: Enable I3C and SPD5118 hwmon Akhil R
2026-06-16 9:54 ` Akhil R
2026-06-16 10:10 ` sashiko-bot
2026-06-16 10:10 ` 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=20260616101738.CF6891F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=akhilrajeev@nvidia.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.