Re: [PATCH] scsi: smartpqi: add support for CCISS_BIG_PASSTHRU ioctl

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unbounded user-controlled kmalloc and hardware transfer violation in pqi_big_passthru_ioctl
--

--- Patch [1]: [PATCH] scsi: smartpqi: add support for CCISS_BIG_PASSTHRU ioctl ---
commit 76afabc08948098cc8542c214646dcdc2c4154bf
Author: David Strahan <David.Strahan@microchip.com>

scsi: smartpqi: add support for CCISS_BIG_PASSTHRU ioctl

This commit adds pqi_big_passthru_ioctl() to handle CCISS_BIG_PASSTHRU ioctl
requests. It allows larger transfer sizes by using BIG_IOCTL_Command_struct
which stores the buffer size as a 32-bit integer.

> diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
> --- a/drivers/scsi/smartpqi/smartpqi_init.c
> +++ b/drivers/scsi/smartpqi/smartpqi_init.c
[ ... ]
> @@ -6918,6 +6918,144 @@ static int pqi_passthru_ioctl(struct pqi_ctrl_info *ctrl_info, void __user *arg)
[ ... ]
> +static int pqi_big_passthru_ioctl(struct pqi_ctrl_info *ctrl_info, void __user *arg)
> +{
[ ... ]
> +	if (iocommand.buf_size > 0) {
> +		kernel_buffer = kmalloc(iocommand.buf_size, GFP_KERNEL);

[Severity: High]
Since buf_size is a 32-bit integer controlled by userspace, can passing it
directly to kmalloc() with GFP_KERNEL cause page allocation warnings or
trigger memory pressure if the size is excessively large?

Could this allocation benefit from bounds checking or __GFP_NOWARN?

> +		if (!kernel_buffer)
> +			return -ENOMEM;
[ ... ]
> +	if (iocommand.buf_size > 0) {
> +		put_unaligned_le32(iocommand.buf_size, &request.buffer_length);
> +
> +		rc = pqi_map_single(ctrl_info->pci_dev,
> +			&request.sg_descriptors[0], kernel_buffer,
> +			iocommand.buf_size, DMA_BIDIRECTIONAL);

[Severity: High]
Does mapping the entire contiguous buffer into a single SG descriptor ignore
the hardware's max_transfer_size limits and the malloc_size chunking
mechanism?

The BIG_IOCTL_Command_struct is explicitly designed to break large transfers
into malloc_size chunks across multiple SG entries. This implementation
places everything into a single descriptor. Can sending an unchunked oversized
DMA request crash the controller firmware or cause a hardware hang?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722202327.5242-2-david.strahan@microchip.com?part=1