From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH RFC 1/7] i3c: master: Support IBI-based wakeup capability
Date: Wed, 01 Jul 2026 20:26:23 +0000 [thread overview]
Message-ID: <20260701202624.18BA31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701200552.220042-2-adrian.hunter@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Dangling pointer and double free on device_register() error path
- [High] Missing of_node_get() causes Use-After-Free of device tree node
--
commit ea80dbce0f5cdda7818e80b6dab51dc68f768d72
Author: Adrian Hunter <adrian.hunter@intel.com>
i3c: master: Support IBI-based wakeup capability
Adds an ibi_wakeup flag to struct i3c_master_controller so controller
drivers can advertise support for IBI-based wakeup. If set, marks
IBI-capable I3C devices as wakeup capable when they are registered.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f1be38a640ca1..a47e2924bb701 100644
> --- 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 need to
increment the reference count of the device tree node using of_node_get()?
Currently, the node is assigned directly from desc->boardinfo->of_node.
However, when the I3C device is later released (either via unregistration or
a device_register() failure), i3c_device_release() unconditionally calls
of_node_put(i3cdev->dev.of_node).
Could this consume the reference conceptually owned by boardinfo and lead to
a use-after-free of the device node on repeated hot-plug cycles or
registration failures?
> + /*
> + * 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 is it possible for this error path to
leave a dangling pointer that causes a use-after-free later?
If device_register() fails, put_device() frees desc->dev via
i3c_device_release(). However, desc->dev and desc->dev->desc are not
cleared.
If i3c_master_unregister_i3c_devs() is later invoked during driver unbind,
it appears to find the non-NULL pointer and write to freed memory:
i3c_master_unregister_i3c_devs() {
...
i3cdev->dev->desc = NULL;
if (device_is_registered(&i3cdev->dev->dev))
device_unregister(&i3cdev->dev->dev);
else
put_device(&i3cdev->dev->dev);
...
}
and then execute a double-free on the device object. Should this error path
clear desc->dev to prevent this?
> }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701200552.220042-1-adrian.hunter@intel.com?part=1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-07-01 20:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 20:05 [PATCH RFC 0/7] i3c: Support IBI-based system wakeup Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:05 ` [PATCH RFC 1/7] i3c: master: Support IBI-based wakeup capability Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:26 ` sashiko-bot [this message]
2026-07-01 20:05 ` [PATCH RFC 2/7] i3c: master: Report wakeup events for IBIs Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:27 ` sashiko-bot
2026-07-01 20:05 ` [PATCH RFC 3/7] i3c: master: Add helper to query bus wakeup requirements Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:23 ` sashiko-bot
2026-07-01 20:05 ` [PATCH RFC 4/7] i3c: master: Reject IBI requests from non-IBI-capable devices Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:05 ` [PATCH RFC 5/7] i3c: mipi-i3c-hci-pci: Propagate I3C wakeup requirements to PCI Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:26 ` sashiko-bot
2026-07-01 20:05 ` [PATCH RFC 6/7] i3c: mipi-i3c-hci: Factor out i3c_hci_sysdev() Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:05 ` [PATCH RFC 7/7] i3c: mipi-i3c-hci: Advertise IBI wakeup capability Adrian Hunter
2026-07-01 20:05 ` Adrian Hunter
2026-07-01 20:15 ` [PATCH RFC 0/7] i3c: Support IBI-based system wakeup Adrian Hunter
2026-07-01 20:15 ` Adrian Hunter
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=20260701202624.18BA31F000E9@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=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.