From: sashiko-bot@kernel.org
To: "Ranjan Kumar" <ranjan.kumar@broadcom.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v4 04/10] mpi3mr: Fix NVMe page size caching for non-operational devices
Date: Wed, 05 Aug 2026 11:40:21 +0000 [thread overview]
Message-ID: <20260805114022.444C91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805110634.346670-5-ranjan.kumar@broadcom.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Time-of-Check to Time-of-Use (TOCTOU) / Double Fetch vulnerability in NVMe page size validation
--
--- Patch [4]: [PATCH v4 04/10] mpi3mr: Fix NVMe page size caching for non-operational devices ---
commit 84a34ae29dcd95f3e4be7fc74958e61313bd07c9
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>
mpi3mr: Fix NVMe page size caching for non-operational devices
This commit populates the NVMe page size attribute irrespective of device
access status so firmware can process IOCTLs and report appropriate errors.
It also adds bounds checking for page_size to prevent undefined shift
behavior, and initializes timeout values via local variables to avoid race
conditions.
Closes: https://sashiko.dev/#/patchset/20260626114109.43685-1-ranjan.kumar@broadcom.com?part=4
Closes: https://sashiko.dev/#/patchset/20260708183305.244485-1-ranjan.kumar@broadcom.com?part=4
Closes: https://sashiko.dev/#/patchset/20260724102505.115136-1-ranjan.kumar@broadcom.com?part=4
> diff --git a/drivers/scsi/mpi3mr/mpi3mr_os.c b/drivers/scsi/mpi3mr/mpi3mr_os.c
> index d2a20f2721dbf..88b1d6360dac2 100644
> --- a/drivers/scsi/mpi3mr/mpi3mr_os.c
> +++ b/drivers/scsi/mpi3mr/mpi3mr_os.c
[ ... ]
> @@ -1349,24 +1349,32 @@ static void mpi3mr_update_tgtdev(struct mpi3mr_ioc *mrioc,
> struct mpi3_device0_pcie_format *pcieinf =
> &dev_pg0->device_specific.pcie_format;
> u16 dev_info = le16_to_cpu(pcieinf->device_info);
> + u8 pgsz = MPI3MR_DEFAULT_PGSZEXP;
> + u8 reset_to = MPI3MR_INTADMCMD_TIMEOUT;
> + u8 abort_to = MPI3MR_INTADMCMD_TIMEOUT;
>
> tgtdev->dev_spec.pcie_inf.dev_info = dev_info;
> tgtdev->dev_spec.pcie_inf.capb =
> le32_to_cpu(pcieinf->capabilities);
> tgtdev->dev_spec.pcie_inf.mdts = MPI3MR_DEFAULT_MDTS;
> - /* 2^12 = 4096 */
> - tgtdev->dev_spec.pcie_inf.pgsz = 12;
> + /* Validate firmware page size to prevent undefined shift behavior */
> + if (pcieinf->page_size >= MPI3MR_DEFAULT_PGSZEXP &&
> + pcieinf->page_size <= MPI3MR_MAX_PGSZEXP)
> + pgsz = pcieinf->page_size;
[Severity: High]
Could this introduce a time-of-check to time-of-use (TOCTOU) double fetch
vulnerability?
Since pcieinf points into dev_pg0, which resides directly in the DMA-mapped
reply buffer, is it possible for a compromised or malfunctioning PCIe device
to modify pcieinf->page_size in memory between the bounds check evaluation
and the final assignment?
If the device changes the value right after the check passes, an out-of-bounds
value might be stored into pgsz, bypassing the validation and potentially
triggering the undefined shift behavior this patch aims to prevent.
Would it be safer to fetch pcieinf->page_size into a local variable using
READ_ONCE() and then perform the validation and assignment on that local copy?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805110634.346670-1-ranjan.kumar@broadcom.com?part=4
next prev parent reply other threads:[~2026-08-05 11:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 11:06 [PATCH v4 00/10] mpi3mr: Few Enhancements and minor fixes Ranjan Kumar
2026-08-05 11:06 ` [PATCH v4 01/10] mpi3mr: Skip device shutdown during unload per controller configuration Ranjan Kumar
2026-08-05 11:33 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 02/10] mpi3mr: Update MPI Headers to revision 41 Ranjan Kumar
2026-08-05 11:33 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 03/10] mpi3mr: Add early timestamp synchronization after driver load Ranjan Kumar
2026-08-05 11:06 ` [PATCH v4 04/10] mpi3mr: Fix NVMe page size caching for non-operational devices Ranjan Kumar
2026-08-05 11:40 ` sashiko-bot [this message]
2026-08-05 11:06 ` [PATCH v4 05/10] mpi3mr: Fix performance regression caused by extended IRQ poll sleep Ranjan Kumar
2026-08-05 11:32 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 06/10] mpi3mr: Fix memory leak on operational queue creation failure Ranjan Kumar
2026-08-05 11:40 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 07/10] mpi3mr: Fix firmware event reference leak during cleanup Ranjan Kumar
2026-08-05 11:38 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 08/10] mpi3mr: Fix SAS port allocation and registration error handling Ranjan Kumar
2026-08-05 11:40 ` sashiko-bot
2026-08-05 11:06 ` [PATCH v4 09/10] mpi3mr: Fix SAS PHY cleanup in host addition error paths Ranjan Kumar
2026-08-05 11:06 ` [PATCH v4 10/10] mpi3mr: Driver version update to 8.18.0.8.50 Ranjan Kumar
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=20260805114022.444C91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ranjan.kumar@broadcom.com \
--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