All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Niklas Cassel" <cassel@kernel.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write
Date: Thu, 17 Sep 2026 13:04:15 +0000	[thread overview]
Message-ID: <20260917130415.9A2A21F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917125445.1376493-9-cassel@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi_debug: unsigned underflow in resp_write_scat() residual calculation
--

commit a487bfccdf1b47222ab79a838751982d68882fc7
Author: Niklas Cassel <cassel@kernel.org>
Subject: scsi: scsi_debug: Report the residual of a write

This patch updates the write paths in scsi_debug to report residual
bytes when a buffer provided by the initiator is larger than the logical
blocks consumed. The residual is now reported in resp_write_dt0(),
resp_write_scat(), and resp_atomic_write().

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 6941809dfdb75..641dd6f937912 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
[ ... ]
> @@ -5352,6 +5354,7 @@ static int resp_write_scat(struct scsi_cmnd *scp,
>  		sg_off += num_by;
>  		cum_lb += num;
>  	}
> +	scsi_set_resid(scp, scsi_bufflen(scp) - sg_off);

[Severity: High]
Can this calculation result in an unsigned underflow if the initiator
provides a buffer shorter than what the CDB descriptors request?

In resp_write_scat(), sg_off tracks the data offset. For each LBA range
descriptor, sg_off is unconditionally incremented by num_by, which is the
size requested by the descriptor. This happens even if do_device_access()
copied less data due to hitting the end of the data-out buffer.

If the initiator provides a shorter buffer (scsi_bufflen) than what the
CDB descriptors request, sg_off will eventually exceed the buffer length.
The subtraction here would then underflow to a massive positive number.

The SCSI midlayer uses this residual to compute good_bytes in
scsi_io_completion(). Subtracting a massive residual from the expected
transfer length could cause good_bytes to wrap and become negative, which
might severely confuse the block layer I/O completion logic.

>  	ret = 0;
>  err_out_unlock:
>  	sdeb_meta_write_unlock(sip);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917125445.1376493-8-cassel@kernel.org?part=1

  reply	other threads:[~2026-09-17 13:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 12:54 [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-17 12:54 ` [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write Niklas Cassel
2026-09-17 13:04   ` sashiko-bot [this message]
2026-09-17 13:06   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 2/6] scsi: scsi_debug: Do not write a partial physical block Niklas Cassel
2026-09-17 13:11   ` Damien Le Moal
2026-09-17 13:47     ` Niklas Cassel
2026-09-17 12:54 ` [PATCH v3 3/6] scsi: scsi_debug: Advance the write pointer over the data written Niklas Cassel
2026-09-17 13:13   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 13:09   ` sashiko-bot
2026-09-17 12:54 ` [PATCH v3 5/6] scsi: scsi_debug: Map the region written by WRITE ATOMIC (16) Niklas Cassel
2026-09-17 13:12   ` sashiko-bot
2026-09-17 14:01     ` Niklas Cassel
2026-09-17 13:14   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 6/6] scsi: scsi_debug: Validate zone access for " Niklas Cassel
2026-09-17 13:15   ` Damien Le Moal
2026-09-17 13:05 ` [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Damien Le Moal

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=20260917130415.9A2A21F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cassel@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.