From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
Frank.Li@kernel.org, linux-i3c@lists.infradead.org
Subject: Re: [PATCH 13/17] i3c: mipi-i3c-hci: Remove invalid transfer size limit
Date: Mon, 14 Sep 2026 11:49:31 +0000 [thread overview]
Message-ID: <20260914114932.30B8C1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914113003.183150-14-adrian.hunter@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds write in `hci_pio_do_trailing_rx` due to trusting hardware-provided response data length.
--
commit 3ab8715cd2bb671d95cd856e91ac9ea00583f567
Author: Adrian Hunter <adrian.hunter@intel.com>
i3c: mipi-i3c-hci: Remove invalid transfer size limit
The driver derives a maximum transfer size from HC_CAP_MAX_DATA_LENGTH in
HC_CAPABILITIES, but no published version of the I3C HCI specification
defines such a field. This commit removes the unused capability definition
and the dead size check.
> diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
> index b9b20797d0454..4629a16debc98 100644
> --- a/drivers/i3c/master/mipi-i3c-hci/core.c
> +++ b/drivers/i3c/master/mipi-i3c-hci/core.c
[ ... ]
> @@ -482,13 +480,8 @@ static int i3c_hci_i3c_xfers(struct i3c_dev_desc *dev,
> if (!xfer)
> return -ENOMEM;
>
> - size_limit = 1U << (16 + FIELD_GET(HC_CAP_MAX_DATA_LENGTH, hci->caps));
> -
> for (i = 0; i < nxfers; i++) {
> xfer[i].data_len = i3c_xfers[i].len;
> - ret = -EFBIG;
> - if (xfer[i].data_len >= size_limit)
> - goto out;
[Severity: High]
This is a pre-existing issue, but could this lead to an out-of-bounds write
during response processing?
If the I3C HCI controller hardware returns a response descriptor with a data
length (RESP_DATA_LENGTH) greater than the originally requested buffer size
stored here in xfer->data_len, it appears the hardware-provided value is
trusted without being bounded.
In drivers/i3c/master/mipi-i3c-hci/pio.c:hci_pio_process_resp():
received = xfer->data_len - xfer->data_left;
expected = RESP_DATA_LENGTH(xfer->response);
if (expected > received) {
hci_pio_do_trailing_rx(hci, pio, expected - received);
}
This leads to an oversized count being passed to hci_pio_do_trailing_rx():
drivers/i3c/master/mipi-i3c-hci/pio.c:hci_pio_do_trailing_rx() {
...
if (count >= 4) {
unsigned int nr_words = count / 4;
/* extract data from FIFO */
xfer->data_left -= nr_words * 4;
dev_dbg(&hci->master.dev, "now %d left %d",
nr_words * 4, xfer->data_left);
while (nr_words--)
*p++ = pio_reg_read(XFER_DATA_PORT);
}
...
}
Will this unconditionally read the extra bytes from the hardware FIFO into
the memory pointed to by p, overflowing the xfer->data buffer if a faulty
or malicious target device induces the master to read more data than
requested?
> xfer[i].rnw = i3c_xfers[i].rnw;
> if (i3c_xfers[i].rnw) {
> xfer[i].data = i3c_xfers[i].data.in;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914113003.183150-1-adrian.hunter@intel.com?part=13
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-09-14 11:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 11:29 [PATCH 00/17] i3c: Fixes, cleanups and HDR-DDR support Adrian Hunter
2026-09-14 11:29 ` [PATCH 01/17] i3c: master: Fix out-of-bounds read in DMA bounce buffer setup Adrian Hunter
2026-09-14 16:09 ` Frank Li
2026-09-14 11:29 ` [PATCH 02/17] i3c: mipi-i3c-hci: Bounce short reads irrespective of the IOMMU Adrian Hunter
2026-09-14 16:16 ` Frank Li
2026-09-14 11:29 ` [PATCH 03/17] i3c: mipi-i3c-hci-pci: Set drvdata before creating LTR sysfs attribute Adrian Hunter
2026-09-14 11:45 ` sashiko-bot
2026-09-14 16:17 ` Frank Li
2026-09-14 11:29 ` [PATCH 04/17] i3c: master: Match ACPI targets to the correct bus controller instance Adrian Hunter
2026-09-14 11:50 ` sashiko-bot
2026-09-14 16:19 ` Frank Li
2026-09-14 11:29 ` [PATCH 05/17] i3c: master: Remove stale GETSTATUS length check Adrian Hunter
2026-09-14 16:23 ` Frank Li
2026-09-14 11:29 ` [PATCH 06/17] i3c: mipi-i3c-hci: Fix i3c_hci_enable_ibi() error path Adrian Hunter
2026-09-14 11:46 ` sashiko-bot
2026-09-14 16:27 ` Frank Li
2026-09-14 11:29 ` [PATCH 07/17] i3c: mipi-i3c-hci: Send DISEC before disabling IBIs in hardware Adrian Hunter
2026-09-14 16:29 ` Frank Li
2026-09-14 11:29 ` [PATCH 08/17] i3c: mipi-i3c-hci: Fix runtime PM violation in i3c_hci_free_ibi() Adrian Hunter
2026-09-14 11:58 ` sashiko-bot
2026-09-14 11:29 ` [PATCH 09/17] i3c: mipi-i3c-hci: Process multiple IBIs per interrupt Adrian Hunter
2026-09-14 16:45 ` Frank Li
2026-09-15 9:36 ` Adrian Hunter
2026-09-14 11:29 ` [PATCH 10/17] i3c: mipi-i3c-hci: Move DMA suspend/resume callbacks Adrian Hunter
2026-09-14 16:46 ` Frank Li
2026-09-14 11:29 ` [PATCH 11/17] i3c: mipi-i3c-hci: Stop rings gracefully when suspending Adrian Hunter
2026-09-14 16:51 ` Frank Li
2026-09-14 11:29 ` [PATCH 12/17] i3c: mipi-i3c-hci: Fix Response Descriptor DATA_LENGTH mask Adrian Hunter
2026-09-14 11:48 ` sashiko-bot
2026-09-14 16:55 ` Frank Li
2026-09-14 11:29 ` [PATCH 13/17] i3c: mipi-i3c-hci: Remove invalid transfer size limit Adrian Hunter
2026-09-14 11:49 ` sashiko-bot [this message]
2026-09-14 16:58 ` Frank Li
2026-09-14 11:30 ` [PATCH 14/17] i3c: mipi-i3c-hci: Remove invalid HDR-BT and Fm/Fm+ definitions Adrian Hunter
2026-09-14 17:00 ` Frank Li
2026-09-14 11:30 ` [PATCH 15/17] i3c: mipi-i3c-hci: Support configurable device NACK retries Adrian Hunter
2026-09-14 11:56 ` sashiko-bot
2026-09-14 18:21 ` Frank Li
2026-09-15 9:41 ` Adrian Hunter
2026-09-14 11:30 ` [PATCH 16/17] i3c: Restrict HDR modes to those supported by the bus and target Adrian Hunter
2026-09-14 18:26 ` Frank Li
2026-09-14 11:30 ` [PATCH 17/17] i3c: mipi-i3c-hci: Add HDR-DDR support Adrian Hunter
2026-09-14 11:54 ` sashiko-bot
2026-09-14 12:54 ` Adrian Hunter
2026-09-14 18:32 ` Frank Li
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=20260914114932.30B8C1F000FF@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox