All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: linux-i3c@lists.infradead.org, linux-pci@vger.kernel.org,
	Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH RFC RESEND 1/7] i3c: master: Support IBI-based wakeup capability
Date: Wed, 01 Jul 2026 20:30:53 +0000	[thread overview]
Message-ID: <20260701203053.8F3971F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701201533.220818-2-adrian.hunter@intel.com>

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

Pre-existing issues:
- [High] Use-After-Free and double-free of I3C device due to dangling pointer on device_register() failure.
- [High] Reference count underflow of OF node due to missing of_node_get() during device registration.
--

commit 9efcfa1df1912edf83596e1ebd38559fc710aaca
Author: Adrian Hunter <adrian.hunter@intel.com>

i3c: master: Support IBI-based wakeup capability

This patch adds an ibi_wakeup flag to the I3C master controller. It allows
IBI-capable I3C devices to be marked as wakeup capable during registration
if the controller supports waking the system via In-Band Interrupts.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -1930,6 +1931,13 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
>  		if (desc->boardinfo)
>  			desc->dev->dev.of_node = desc->boardinfo->of_node;

[Severity: High]
This isn't a bug introduced by this patch, but does this assignment cause
an OF node reference count underflow?

The pointer is assigned without taking a new reference via of_node_get().
However, when the device is freed, i3c_device_release() unconditionally
calls of_node_put(i3cdev->dev.of_node).

If device_register() fails just below this, or when the device is eventually
unregistered, the release function will drop a reference that was never
acquired for the device itself.

>  
> +		/*
> +		 * In the case of IBI wakeup, any IBI-capable device can
> +		 * wakeup.
> +		 */
> +		if (master->ibi_wakeup && (desc->info.bcr & I3C_BCR_IBI_REQ_CAP))
> +			device_set_wakeup_capable(&desc->dev->dev, true);
> +
>  		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 causes a use-after-free and double-free later?

If device_register() fails, put_device() is called which frees desc->dev
via i3c_device_release(), but desc->dev is never set to NULL.

Later, during controller teardown, i3c_master_unregister_i3c_devs()
iterates over the bus and checks if (!i3cdev->dev). Since the pointer
wasn't cleared, it proceeds to dereference it and free it again:

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

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

Should desc->dev be set to NULL after the put_device() call here?

>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701201533.220818-1-adrian.hunter@intel.com?part=1

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

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: linux-i3c@lists.infradead.org, linux-pci@vger.kernel.org,
	Frank.Li@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH RFC RESEND 1/7] i3c: master: Support IBI-based wakeup capability
Date: Wed, 01 Jul 2026 20:30:53 +0000	[thread overview]
Message-ID: <20260701203053.8F3971F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701201533.220818-2-adrian.hunter@intel.com>

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

Pre-existing issues:
- [High] Use-After-Free and double-free of I3C device due to dangling pointer on device_register() failure.
- [High] Reference count underflow of OF node due to missing of_node_get() during device registration.
--

commit 9efcfa1df1912edf83596e1ebd38559fc710aaca
Author: Adrian Hunter <adrian.hunter@intel.com>

i3c: master: Support IBI-based wakeup capability

This patch adds an ibi_wakeup flag to the I3C master controller. It allows
IBI-capable I3C devices to be marked as wakeup capable during registration
if the controller supports waking the system via In-Band Interrupts.

> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -1930,6 +1931,13 @@ i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
>  		if (desc->boardinfo)
>  			desc->dev->dev.of_node = desc->boardinfo->of_node;

[Severity: High]
This isn't a bug introduced by this patch, but does this assignment cause
an OF node reference count underflow?

The pointer is assigned without taking a new reference via of_node_get().
However, when the device is freed, i3c_device_release() unconditionally
calls of_node_put(i3cdev->dev.of_node).

If device_register() fails just below this, or when the device is eventually
unregistered, the release function will drop a reference that was never
acquired for the device itself.

>  
> +		/*
> +		 * In the case of IBI wakeup, any IBI-capable device can
> +		 * wakeup.
> +		 */
> +		if (master->ibi_wakeup && (desc->info.bcr & I3C_BCR_IBI_REQ_CAP))
> +			device_set_wakeup_capable(&desc->dev->dev, true);
> +
>  		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 causes a use-after-free and double-free later?

If device_register() fails, put_device() is called which frees desc->dev
via i3c_device_release(), but desc->dev is never set to NULL.

Later, during controller teardown, i3c_master_unregister_i3c_devs()
iterates over the bus and checks if (!i3cdev->dev). Since the pointer
wasn't cleared, it proceeds to dereference it and free it again:

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

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

Should desc->dev be set to NULL after the put_device() call here?

>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701201533.220818-1-adrian.hunter@intel.com?part=1

  reply	other threads:[~2026-07-01 20:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 20:15 [PATCH RFC RESEND 0/7] i3c: Support IBI-based system wakeup Adrian Hunter
2026-07-01 20:15 ` Adrian Hunter
2026-07-01 20:15 ` [PATCH RFC RESEND 1/7] i3c: master: Support IBI-based wakeup capability Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:30   ` sashiko-bot [this message]
2026-07-01 20:30     ` sashiko-bot
2026-07-02 14:10   ` Frank Li
2026-07-02 14:10     ` Frank Li
2026-07-01 20:15 ` [PATCH RFC RESEND 2/7] i3c: master: Report wakeup events for IBIs Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:33   ` sashiko-bot
2026-07-01 20:33     ` sashiko-bot
2026-07-02 10:38     ` Adrian Hunter
2026-07-02 10:38       ` Adrian Hunter
2026-07-01 20:15 ` [PATCH RFC RESEND 3/7] i3c: master: Add helper to query bus wakeup requirements Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:33   ` sashiko-bot
2026-07-01 20:33     ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 4/7] i3c: master: Reject IBI requests from non-IBI-capable devices Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:29   ` sashiko-bot
2026-07-01 20:29     ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 5/7] i3c: mipi-i3c-hci-pci: Propagate I3C wakeup requirements to PCI Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:33   ` sashiko-bot
2026-07-01 20:33     ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 6/7] i3c: mipi-i3c-hci: Factor out i3c_hci_sysdev() Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:23   ` sashiko-bot
2026-07-01 20:23     ` sashiko-bot
2026-07-01 20:15 ` [PATCH RFC RESEND 7/7] i3c: mipi-i3c-hci: Advertise IBI wakeup capability Adrian Hunter
2026-07-01 20:15   ` Adrian Hunter
2026-07-01 20:22   ` sashiko-bot
2026-07-01 20:22     ` 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=20260701203053.8F3971F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-pci@vger.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.