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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox