[SRU][P:linux-azure][PATCH 4/4] scsi: storvsc: Set correct data length for sending SCSI command without payload

John Cabaj john.cabaj at canonical.com
Fri Feb 21 21:39:49 UTC 2025


From: Long Li <longli at microsoft.com>

BugLink: https://bugs.launchpad.net/bugs/2098508

In StorVSC, payload->range.len is used to indicate if this SCSI command
carries payload. This data is allocated as part of the private driver data
by the upper layer and may get passed to lower driver uninitialized.

For example, the SCSI error handling mid layer may send TEST_UNIT_READY or
REQUEST_SENSE while reusing the buffer from a failed command. The private
data section may have stale data from the previous command.

If the SCSI command doesn't carry payload, the driver may use this value as
is for communicating with host, resulting in possible corruption.

Fix this by always initializing this value.

Fixes: be0cf6ca301c ("scsi: storvsc: Set the tablesize based on the information given by the host")
Cc: stable at kernel.org
Tested-by: Roman Kisel <romank at linux.microsoft.com>
Reviewed-by: Roman Kisel <romank at linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux at outlook.com>
Signed-off-by: Long Li <longli at microsoft.com>
Link: https://lore.kernel.org/r/1737601642-7759-1-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Martin K. Petersen <martin.petersen at oracle.com>
(cherry picked from commit 87c4b5e8a6b65189abd9ea5010ab308941f964a4)
Signed-off-by: John Cabaj <john.cabaj at canonical.com>
---
 drivers/scsi/storvsc_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d0b55c1fa908..6c89b486b712 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1794,6 +1794,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd)
 
 	length = scsi_bufflen(scmnd);
 	payload = (struct vmbus_packet_mpb_array *)&cmd_request->mpb;
+	payload->range.len = 0;
 	payload_sz = 0;
 
 	if (scsi_sg_count(scmnd)) {
-- 
2.43.0




More information about the kernel-team mailing list