Re: [PATCH] ata: libata-scsi: reject multi-sector taskfile commands when dev->multi_count is 0

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] scsi: incorrect error field pointer for ATA_32 variable length CDBs
--

commit 19f1f1458eecf6dc97d38273c4c750d2aff47ab1
Author: Hui Peng <benquike@gmail.com>

ata: libata-scsi: reject multi-sector taskfile commands when dev->multi_count is 0

This patch rejects ATA_PROT_PIO multi-sector commands with -EINVAL when 
dev->multi_count is 0. It does this by catching the condition early and 
triggering an error path to avoid divide-by-zero or warnings in the 
taskfile path.

> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index d2160ee7ca7d4..3fc4f0377e991 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3473,6 +3473,11 @@ static unsigned int ata_scsi_pass_thru(struct ata_queued_cmd *qc)
>  	if (is_multi_taskfile(tf)) {
>  		unsigned int multi_count = 1 << (cdb[1] >> 5);
>  
> +		if (!dev->multi_count) {
> +			fp = (cdb[0] == ATA_16) ? 14 : 9;

[Severity: Low]
Does this fallback to 9 incorrectly handle ATA_32 variable length CDBs?

When an ATA_32 pass-through command specifies a multi-sector command in
ata_scsi_pass_thru() but the device does not support it, this code rejects
the command and sets the invalid field pointer (fp) to 9. For an ATA_12
command, byte 9 is the command field, but for an ATA_32 variable length CDB
(opcode 0x7F), byte 9 is the Service Action lower byte, and the command
field is at byte 25.

Could this result in the SCSI sense data incorrectly pointing to byte 9
instead of byte 25 on the error path for ATA_32 commands?

> +			goto invalid_fld;
> +		}
> +
>  		/* compare the passed through multi_count
>  		 * with the cached multi_count of libata
>  		 */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919222625.3797581-1-benquike@gmail.com?part=1