From: sashiko-bot@kernel.org
To: "Adrian Hunter" <adrian.hunter@intel.com>
Cc: Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH 12/17] i3c: mipi-i3c-hci: Fix Response Descriptor DATA_LENGTH mask
Date: Mon, 14 Sep 2026 11:48:16 +0000 [thread overview]
Message-ID: <20260914114816.680481F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914113003.183150-13-adrian.hunter@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The driver blindly trusts the `RESP_DATA_LENGTH` reported by the hardware response descriptor without validating it against the originally requested transfer length (`xfer->data_len`). This allows a buggy or malicious I3C hardware controller to cause an out-of-bounds heap memory write. Specifically, in `hci_pio_process_resp()`, if the hardware reports an `expected` length greater than `received` (which is bounded by `xfer->data_len`), it calls `hci_pio_do_trailing_rx()` with the difference. The `hci_pio_do_trailing_rx()` function then reads this many words from the FIFO and writes them into `xfer->data` without any bounds checking against the allocated buffer size. Furthermore, in `i3c_hci_send_ccc_cmd()` and `i3c_hci_i3c_xfers()`, the unvalidated `RESP_DATA_LENGTH` is copied into the payload or transfer length fields, causing upper layers to potentially trust this mutated length, leading to information leaks or further bounds violations.
--
commit 1331b71b6fc3650effd8b493f413537d7aac5b39
Author: Adrian Hunter <adrian.hunter@intel.com>
i3c: mipi-i3c-hci: Fix Response Descriptor DATA_LENGTH mask
The I3C HCI Response Descriptor defines DATA_LENGTH in Bits[15:0],
with Bits[23:16] reserved in all published HCI specification versions.
This updates the RESP_DATA_LENGTH mask to extract only the 16 defined
bits, correcting the previous inclusion of six reserved bits.
> diff --git a/drivers/i3c/master/mipi-i3c-hci/cmd.h b/drivers/i3c/master/mipi-i3c-hci/cmd.h
> index 7bada7b4b2de5..e0d4a6e0e319f 100644
> --- a/drivers/i3c/master/mipi-i3c-hci/cmd.h
> +++ b/drivers/i3c/master/mipi-i3c-hci/cmd.h
> @@ -24,7 +24,7 @@
> */
> #define RESP_STATUS(resp) FIELD_GET(GENMASK(31, 28), resp)
> #define RESP_TID(resp) FIELD_GET(GENMASK(27, 24), resp)
> -#define RESP_DATA_LENGTH(resp) FIELD_GET(GENMASK(21, 0), resp)
> +#define RESP_DATA_LENGTH(resp) FIELD_GET(GENMASK(15, 0), resp)
[Severity: Critical]
This is a pre-existing issue, but does the driver blindly trust the
RESP_DATA_LENGTH reported by the hardware response descriptor without
validating it against the originally requested transfer length?
If a buggy or malicious I3C hardware controller reports an expected length
greater than the requested transfer length (xfer->data_len), could this
lead to an out-of-bounds heap memory write?
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);
If expected is greater than received, this passes the difference to
hci_pio_do_trailing_rx().
This function appears to read that many words from the FIFO without
bounds checking against the allocated buffer size:
drivers/i3c/master/mipi-i3c-hci/pio.c:hci_pio_do_trailing_rx():
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);
Additionally, does this unvalidated hardware response length overwrite the
transfer or payload lengths returned to upper layers?
For instance, in drivers/i3c/master/mipi-i3c-hci/core.c:i3c_hci_i3c_xfers():
for (i = 0; i < nxfers; i++) {
if (xfer[i].rnw)
i3c_xfers[i].len = RESP_DATA_LENGTH(xfer[i].response);
And in drivers/i3c/master/mipi-i3c-hci/core.c:i3c_hci_send_ccc_cmd():
for (i = prefixed; i < nxfers; i++) {
if (ccc->rnw)
ccc->dests[i - prefixed].payload.actual_len =
RESP_DATA_LENGTH(xfer[i].response);
>
> #define RESP_ERR_FIELD GENMASK(31, 28)
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914113003.183150-1-adrian.hunter@intel.com?part=12
--
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:48 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 [this message]
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
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=20260914114816.680481F000FF@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.