From: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
To: "Martin K . Petersen" <mkp@kernel.org>,
"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, yhlee@isslab.korea.ac.kr
Subject: [PATCH v6 3/5] scsi: mvumi: bound the hotplug event bitmap
Date: Thu, 15 Oct 2026 01:24:11 +0900 [thread overview]
Message-ID: <20261014162413.3649841-4-yhlee@isslab.korea.ac.kr> (raw)
In-Reply-To: <20261014162413.3649841-1-yhlee@isslab.korea.ac.kr>
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.
Nothing checks it against the buffer, which mvumi_get_event() allocates at
a fixed 512 bytes, and size is a u16, so a firmware reporting 65535 makes
both scans run roughly 8 KiB past the allocation and places the second
bitmap past it to begin with.
Reject a size whose bitmaps do not fit. The second bitmap starts size bits
in and find_next_zero_bit() reads a long at a time, so that span is the
furthest either scan reaches. Compare it against sizeof(struct
mvumi_event_req), the only length the driver ever puts in
data_transfer_length and therefore the most the firmware may write into the
shared buffer, rather than against the buffer itself: dma_alloc_coherent()
hands back zeroed memory, a zero bit in these bitmaps means a device is
present, so scanning past what the firmware wrote would add devices that do
not exist. Read size once, since it lives in memory the firmware can still
write, and give the buffer size a name while here.
Fixes: bd756ddea18e ("[SCSI] mvumi: Add support for Marvell SAS/SATA RAID-on-Chip(ROC) 88RC9580")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
---
drivers/scsi/mvumi.c | 18 ++++++++++++++++--
drivers/scsi/mvumi.h | 3 +++
2 files changed, 19 insertions(+), 2 deletions(-)
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);
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;
+ }
+
if (mhba->fw_flag & MVUMI_FW_ATTACH) {
index = -1;
ar_bitmap = (const unsigned long *) param->bitmap;
@@ -1708,7 +1722,7 @@ static int mvumi_get_event(struct mvumi_hba *mhba, unsigned char msg)
struct mvumi_cmd *cmd;
struct mvumi_msg_frame *frame;
- cmd = mvumi_create_internal_cmd(mhba, 512);
+ cmd = mvumi_create_internal_cmd(mhba, MVUMI_EVENT_BUF_SIZE);
if (!cmd)
return -1;
cmd->scmd = NULL;
diff --git a/drivers/scsi/mvumi.h b/drivers/scsi/mvumi.h
index 1306a4abf19ad..5d45f0d99e639 100644
--- a/drivers/scsi/mvumi.h
+++ b/drivers/scsi/mvumi.h
@@ -124,6 +124,9 @@ enum {
#define APICDB1_HOST_GETEVENT 1
#define MAX_EVENTS_RETURNED 6
+/* size of the buffer the driver hands the firmware for event replies */
+#define MVUMI_EVENT_BUF_SIZE 512
+
#define DEVICE_OFFLINE 0
#define DEVICE_ONLINE 1
--
2.43.0
next prev parent reply other threads:[~2026-10-14 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 16:24 [PATCH v6 0/5] scsi: mvumi: bound the values the firmware supplies Yehyeong Lee
2026-10-14 16:24 ` [PATCH v6 1/5] scsi: mvumi: bound the per-event parameter and sense dumps Yehyeong Lee
2026-10-14 16:24 ` [PATCH v6 2/5] scsi: mvumi: reject an out-of-range handshake frame length Yehyeong Lee
2026-10-14 16:24 ` Yehyeong Lee [this message]
2026-10-14 16:24 ` [PATCH v6 4/5] scsi: mvumi: reject handshake sizes that overflow the list allocations Yehyeong Lee
2026-10-14 16:24 ` [PATCH v6 5/5] scsi: mvumi: validate the response frame tag before using it 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=20261014162413.3649841-4-yhlee@isslab.korea.ac.kr \
--to=yhlee@isslab.korea.ac.kr \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@kernel.org \
--cc=stable@vger.kernel.org \
/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
all inboxes | Powered by JetHome®