* [PATCH] scsi: megaraid: cap passthrough copyout length
@ 2026-06-24 17:40 Yousef Alhouseen
2026-06-24 17:56 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Yousef Alhouseen @ 2026-06-24 17:40 UTC (permalink / raw)
To: Kashyap Desai, Sumit Saxena, Shivasharan S, Chandrakanth patil
Cc: James E . J . Bottomley, Martin K . Petersen, megaraidlinux.pdl,
linux-scsi, linux-kernel, Yousef Alhouseen
MIMD passthrough commands store the DMA transfer length in dataxferlen.
The common ioctl path copied xferlen bytes back to userspace instead.
For read commands, a larger xferlen can expose stale DMA buffer bytes.
Those bytes are beyond the data returned by the controller.
Validate dataxferlen for both directions and copy back only that length.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/scsi/megaraid/megaraid_mm.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_mm.c b/drivers/scsi/megaraid/megaraid_mm.c
index e57266590..75f6b7198 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -480,12 +480,14 @@ mimd_to_kioc(mimd_t __user *umimd, mraid_mmadp_t *adp, uioc_t *kioc)
return (-EFAULT);
}
+ if (pthru32->dataxferlen > kioc->xferlen)
+ return -EINVAL;
+ kioc->user_data_len = pthru32->dataxferlen;
+
pthru32->dataxferaddr = kioc->buf_paddr;
if (kioc->data_dir & UIOC_WR) {
- if (pthru32->dataxferlen > kioc->xferlen)
- return -EINVAL;
if (copy_from_user(kioc->buf_vaddr, kioc->user_data,
- pthru32->dataxferlen)) {
+ pthru32->dataxferlen)) {
return (-EFAULT);
}
}
--
2.54.0
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH] scsi: megaraid: cap passthrough copyout length
2026-06-24 17:40 [PATCH] scsi: megaraid: cap passthrough copyout length Yousef Alhouseen
@ 2026-06-24 17:56 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-06-24 17:56 UTC (permalink / raw)
To: Yousef Alhouseen; +Cc: linux-scsi
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] DMA buffer overflow leading to physical memory corruption for non-passthrough commands.
- [High] Stale DMA buffer information leak via short reads for both passthrough and non-passthrough commands.
--
commit a08c5cc745806f0bc84fe8025d810aeb7a2f7d82
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
scsi: megaraid: cap passthrough copyout length
MIMD passthrough commands store the DMA transfer length in dataxferlen.
The common ioctl path copied xferlen bytes back to userspace instead.
For read commands, a larger xferlen can expose stale DMA buffer bytes.
> diff --git a/drivers/scsi/megaraid/megaraid_mm.c b/drivers/scsi/megaraid/megaraid_mm.c
> index a70692779a16c..1e49b437e8e5f 100644
> --- a/drivers/scsi/megaraid/megaraid_mm.c
> +++ b/drivers/scsi/megaraid/megaraid_mm.c
> @@ -484,12 +484,14 @@ mimd_to_kioc(mimd_t __user *umimd, mraid_mmadp_t *adp, uioc_t *kioc)
> return (-EFAULT);
> }
>
> + if (pthru32->dataxferlen > kioc->xferlen)
> + return -EINVAL;
> + kioc->user_data_len = pthru32->dataxferlen;
> +
[Severity: High]
This isn't a bug introduced by this patch, but does this still leave an
information leak if the hardware performs a short read?
Since pthru32->dataxferlen is fully user-controlled and does not reflect
the actual byte count transferred by the firmware, a user can request a large
transfer size but send a command that returns fewer bytes.
Because mraid_mm_attach_buf() allocates the DMA buffer without zeroing it,
won't kioc_to_mimd() then copy uninitialized kernel pool memory back to
userspace based on this inflated kioc->user_data_len?
[Severity: Critical]
This is a pre-existing issue, but while this patch fixes the bounds check
for MBOXCMD_PASSTHRU commands, what about regular DCMD commands?
Looking earlier in mimd_to_kioc(), for non-passthrough commands, the driver
copies the raw 14-byte mailbox from userspace:
memcpy(mbox, mimd.mbox, 14);
if (mbox->cmd != MBOXCMD_PASSTHRU) {
mbox->xferaddr = (uint32_t)kioc->buf_paddr;
...
return 0;
}
If a user allocates a small DMA pool buffer via a small mimd.outlen but
embeds a huge transfer size in the raw mailbox payload, there doesn't
appear to be any validation against kioc->xferlen.
When mbox_post_cmd() issues this to the firmware, could it cause an
out-of-bounds DMA transfer into adjacent physical memory?
> pthru32->dataxferaddr = kioc->buf_paddr;
> if (kioc->data_dir & UIOC_WR) {
> - if (pthru32->dataxferlen > kioc->xferlen)
> - return -EINVAL;
> if (copy_from_user(kioc->buf_vaddr, kioc->user_data,
> - pthru32->dataxferlen)) {
> + pthru32->dataxferlen)) {
> return (-EFAULT);
> }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624174053.5274-1-alhouseenyousef@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-24 17:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-24 17:40 [PATCH] scsi: megaraid: cap passthrough copyout length Yousef Alhouseen
2026-06-24 17:56 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox