Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: scsi_debug: zone write pointer incremented on failed ATOMIC WRITE
--

commit 9183d5d7f092b92218c3638f33edc6839086d9f3
Author: Niklas Cassel <cassel@kernel.org>

scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

WRITE ATOMIC (16) is a write command, so on a zoned device it is subject to
the access requirements of the zone that it addresses, and it advances the
write pointer of a sequential write required zone. This patch validates the
access and advances the write pointer holding the zone metadata write lock
across both operations.

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 5a95b7cd7a44c..d52b1f762afb5 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -6209,7 +6209,24 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
[ ... ]
>  	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> +
> +	/* If ZBC zone then bump its write pointer */
> +	if (sdebug_dev_is_zoned(devip)) {
> +		zbc_inc_wp(devip, lba, len);

[Severity: Medium]
Does this code advance the write pointer even if do_device_access() fails?

If a command like WRITE ATOMIC (16) is submitted with an invalid DMA
direction (e.g., DMA_FROM_DEVICE via SG_IO) or a truncated scatter-gather
list, do_device_access() can return -1 or a short length.

Because the write pointer in resp_atomic_write() is incremented before
checking the return value of do_device_access(), the mock device's internal
zone state could become out-of-sync with the simulated physical medium.
This could cause subsequent valid writes to be incorrectly rejected with
UNALIGNED WRITE COMMAND.

> +		sdeb_meta_write_unlock(sip);
> +	}
> +
>  	if (unlikely(ret == -1))
>  		return DID_ERROR << 16;
>  	if (unlikely(ret != len * sdebug_sector_size))
>  		return DID_ERROR << 16;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917084553.559765-4-cassel@kernel.org?part=2