All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yehyeong Lee" <yhlee@isslab.korea.ac.kr>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v8 3/8] scsi: mvumi: bound the hotplug event bitmap
Date: Thu, 15 Oct 2026 02:42:54 +0000	[thread overview]
Message-ID: <sashiko-outbox-172172@kernel.org> (raw)
In-Reply-To: <20261015022728.3936714-4-yhlee@isslab.korea.ac.kr>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: mvumi: missing endianness conversion for firmware size field
--

commit 0540965519d7ac3e42a8417f0ff4a18ecbdc0c77
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

scsi: mvumi: bound the hotplug event bitmap

mvumi_proc_msg() takes size from the hotplug event the firmware DMAs into
the event buffer and uses it twice: as the bit count for two
find_next_zero_bit() scans, and as the byte offset of the second bitmap.
This commit rejects a size whose bitmaps do not fit within the event buffer
to prevent the driver from reading past the allocation.

> diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
> index 2378b676a7a78..9a3dde53dea97 100644
> --- a/drivers/scsi/mvumi.c
> +++ b/drivers/scsi/mvumi.c
> @@ -1652,11 +1652,25 @@ static int mvumi_rescan_bus(void *data)
>  static void mvumi_proc_msg(struct mvumi_hba *mhba,
>  					struct mvumi_hotplug_event *param)
>  {
> -	u16 size = param->size;
> +	u16 size = READ_ONCE(param->size);

[Severity: High]
Does this code miss an endianness conversion for the firmware size field?

The hardware firmware provides a little-endian size, so on big-endian
architectures, a valid small size (e.g., 0x0040) is natively read as a
massive byte-swapped size (0x4000) when le16_to_cpu() isn't used.

Because of the newly introduced bounds check below, this inflated value will
now fail validation, discarding the valid hotplug event entirely and rendering
the driver unable to register attached devices.

>  	const unsigned long *ar_bitmap;
>  	const unsigned long *re_bitmap;
>  	int index;
>  
> +	/*
> +	 * The second bitmap starts size bits into the event buffer and
> +	 * find_next_zero_bit() reads it a long at a time, so that is the
> +	 * furthest the two scans reach.  Bound it by the length the firmware
> +	 * was told it may write, not by the buffer: the bytes past that are
> +	 * still zero, and a zero bit here means a device is present.
> +	 */
> +	if (sizeof(*param) + (size >> 3) + BITS_TO_LONGS(size) * sizeof(long) >
> +			sizeof(struct mvumi_event_req)) {
> +		dev_err(&mhba->pdev->dev,
> +			"invalid hotplug event bitmap size %u\n", size);
> +		return;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015022728.3936714-1-yhlee@isslab.korea.ac.kr?part=3

  reply	other threads:[~2026-10-15  2:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  2:27 [PATCH v8 0/8] scsi: mvumi: bound the values the firmware supplies Yehyeong Lee
2026-10-15  2:27 ` [PATCH v8 1/8] scsi: mvumi: bound the per-event parameter and sense dumps Yehyeong Lee
2026-10-15  2:27 ` [PATCH v8 2/8] scsi: mvumi: reject an out-of-range handshake frame length Yehyeong Lee
2026-10-15  2:41   ` sashiko-bot
2026-10-15  2:27 ` [PATCH v8 3/8] scsi: mvumi: bound the hotplug event bitmap Yehyeong Lee
2026-10-15  2:42   ` sashiko-bot [this message]
2026-10-15  2:27 ` [PATCH v8 4/8] scsi: mvumi: walk the hotplug event bitmap a byte at a time Yehyeong Lee
2026-10-15  2:27 ` [PATCH v8 5/8] scsi: mvumi: reject handshake sizes that overflow the list allocations Yehyeong Lee
2026-10-15  2:40   ` sashiko-bot
2026-10-15  2:27 ` [PATCH v8 6/8] scsi: mvumi: validate the response frame tag before using it Yehyeong Lee
2026-10-15  2:43   ` sashiko-bot
2026-10-15  2:27 ` [PATCH v8 7/8] scsi: mvumi: fix the DMA address rebuilt in mvumi_delete_internal_cmd() Yehyeong Lee
2026-10-15  2:38   ` sashiko-bot
2026-10-15  2:27 ` [PATCH v8 8/8] scsi: mvumi: stamp a consumed outbound list entry out of range Yehyeong Lee

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=sashiko-outbox-172172@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yhlee@isslab.korea.ac.kr \
    /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.