From: sashiko-bot@kernel.org
To: "Yousef Alhouseen" <alhouseenyousef@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2 2/2] scsi: 3w-xxxx: sanitize passthrough SGLs
Date: Thu, 25 Jun 2026 14:08:24 +0000 [thread overview]
Message-ID: <20260625140825.299211F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260625135746.1639-2-alhouseenyousef@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Physical DMA address leak to userspace via `TW_CMD_PACKET_WITH_DATA` ioctl response.
--
commit f37c5fb0d6d5db87dd629b44ae0ac174cd9a5912
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
scsi: 3w-xxxx: sanitize passthrough SGLs
This patch updates TW_CMD_PACKET_WITH_DATA to clear SGL arrays, reject
unknown SGL offsets, and fix the command size. It also zeroes the ioctl
buffer before copying the request to prevent leaking stale memory on short
writes.
> diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
> --- a/drivers/scsi/3w-xxxx.c
> +++ b/drivers/scsi/3w-xxxx.c
[ ... ]
> @@ -966,17 +967,31 @@ static long tw_chrdev_ioctl(struct file *file, unsigned int cmd, unsigned long a
> /* Load the sg list */
> switch (TW_SGL_OUT(tw_ioctl->firmware_command.opcode__sgloffset)) {
> case 2:
> + memset(tw_ioctl->firmware_command.byte8.param.sgl, 0,
> + sizeof(tw_ioctl->firmware_command.byte8.param.sgl));
> + tw_ioctl->firmware_command.size = 4;
> tw_ioctl->firmware_command.byte8.param.sgl[0].address = dma_handle + sizeof(TW_New_Ioctl);
[Severity: High]
This is a pre-existing issue, but does this leak the physical DMA address
to userspace?
In tw_chrdev_ioctl(), the physical DMA address is written into the command
SGL here. After the device finishes processing the request, the driver
copies the command packet back into the firmware_command structure:
memcpy(&(tw_ioctl->firmware_command),
tw_dev->command_packet_virtual_address[request_id],
sizeof(TW_Command));
Finally, this buffer is copied back to user memory:
if (copy_to_user(argp, tw_ioctl, sizeof(TW_New_Ioctl) + data_buffer_length))
Since the structure still contains the kernel-injected physical DMA address,
could this help userspace map the physical memory structure or bypass
protections?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625085842.4522-1-alhouseenyousef@gmail.com?part=2
prev parent reply other threads:[~2026-06-25 14:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 8:58 [PATCH 1/2] scsi: 3w-9xxx: sanitize passthrough SGLs Yousef Alhouseen
2026-06-25 8:58 ` [PATCH 2/2] scsi: 3w-xxxx: " Yousef Alhouseen
2026-06-25 9:26 ` sashiko-bot
2026-06-25 9:31 ` [PATCH 1/2] scsi: 3w-9xxx: " sashiko-bot
2026-06-25 13:57 ` [PATCH v2 " Yousef Alhouseen
2026-06-25 14:15 ` sashiko-bot
2026-06-25 13:57 ` [PATCH v2 2/2] scsi: 3w-xxxx: " Yousef Alhouseen
2026-06-25 14:08 ` sashiko-bot [this message]
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=20260625140825.299211F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alhouseenyousef@gmail.com \
--cc=linux-scsi@vger.kernel.org \
--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