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 v9 3/9] scsi: mvumi: bound the hotplug event bitmap
Date: Thu, 15 Oct 2026 05:08:25 +0000	[thread overview]
Message-ID: <sashiko-outbox-172296@kernel.org> (raw)
In-Reply-To: <20261015045213.3975845-4-yhlee@isslab.korea.ac.kr>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: mvumi: missing endian conversion for param->size
--

commit 67e2f811bb5307d634893d7bcc1a4ae7f4bb47eb
Author: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

scsi: mvumi: bound the hotplug event bitmap

This commit adds a bounds check to mvumi_proc_msg() to prevent scanning
past the allocated event buffer. It reads the size parameter from the
hotplug event and rejects events where the size exceeds expected limits.

> diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
> --- 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: Medium]
Does param->size require an endianness conversion like le16_to_cpu() here?

If the Marvell hardware writes the event buffer in little-endian format
during normal hotplug events, reading param->size natively on a big-endian
host would yield a heavily swapped value.

>  	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)) {

[Severity: Medium]
Since the newly added bounds check in mvumi_proc_msg() relies on this
size value, would an incorrectly swapped size on big-endian hosts cause
this check to spuriously fail and reject valid hotplug events?

> +		dev_err(&mhba->pdev->dev,
> +			"invalid hotplug event bitmap size %u\n", size);
> +		return;
> +	}

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

  reply	other threads:[~2026-10-15  5:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  4:52 [PATCH v9 0/9] scsi: mvumi: bound the values the firmware supplies Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 1/9] scsi: mvumi: bound the per-event parameter and sense dumps Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 2/9] scsi: mvumi: reject an out-of-range handshake frame length Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 3/9] scsi: mvumi: bound the hotplug event bitmap Yehyeong Lee
2026-10-15  5:08   ` sashiko-bot [this message]
2026-10-15  4:52 ` [PATCH v9 4/9] scsi: mvumi: walk the hotplug event bitmap a byte at a time Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 5/9] scsi: mvumi: reject handshake sizes that overflow the list allocations Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 6/9] scsi: mvumi: validate the response frame tag before using it Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 7/9] scsi: mvumi: free the internal command buffer by what was allocated Yehyeong Lee
2026-10-15  5:03   ` sashiko-bot
2026-10-15  5:57     ` Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 8/9] scsi: mvumi: stamp a consumed outbound list entry out of range Yehyeong Lee
2026-10-15  4:52 ` [PATCH v9 9/9] scsi: mvumi: bound the firmware handshake retry loop 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-172296@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.