From: sashiko-bot@kernel.org
To: "Tianyu Lan" <ltykernel@gmail.com>
Cc: linux-hyperv@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH V2 1/1] x86/VMBus: Confidential VMBus for dynamic DMA transfers
Date: Mon, 27 Jul 2026 15:39:24 +0000 [thread overview]
Message-ID: <20260727153925.221C61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727152711.2045-1-tiala@microsoft.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] If storvsc_do_io() returns an error other than -EAGAIN, storvsc_queuecommand() incorrectly returns 0 to the SCSI midlayer, leaking the dynamically allocated payload and causing a command timeout/hang.
--
--- Patch [1]: [PATCH V2 1/1] x86/VMBus: Confidential VMBus for dynamic DMA transfers ---
commit 0fcd974d529c3a7f6e32e98d08ecd19b7a1e7b0a
Author: Tianyu Lan <ltykernel@gmail.com>
x86/VMBus: Confidential VMBus for dynamic DMA transfers
This commit modifies the VMBus driver to support dynamic DMA transfers
for Confidential VMs. It introduces the co_external_memory flag to bypass
the swiotlb and DMA API, allowing direct DMA to private encrypted memory.
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 571ea549152b1..656fe73e0d35e 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
[ ... ]
> @@ -1870,7 +1882,7 @@ static enum scsi_qc_status storvsc_queuecommand(struct Scsi_Host *host,
> ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
> migrate_enable();
>
> - if (ret)
> + if (ret && (!dev->channel->co_external_memory))
> scsi_dma_unmap(scmnd);
>
> if (ret == -EAGAIN) {
[Severity: High]
This is a pre-existing issue, but if storvsc_do_io() returns an error
other than -EAGAIN, does storvsc_queuecommand() leak the payload buffer
and silently drop the error?
If storvsc_do_io() returns a failure like -ENODEV, the code bypasses the
err_free_payload block and returns 0 to the SCSI midlayer:
storvsc_queuecommand() {
...
ret = storvsc_do_io(dev, cmd_request, smp_processor_id());
...
if (ret == -EAGAIN) {
ret = SCSI_MLQUEUE_DEVICE_BUSY;
goto err_free_payload;
}
return 0;
err_free_payload:
if (payload_sz > sizeof(cmd_request->mpb))
kfree(payload);
return ret;
}
Since 0 is returned, the midlayer believes the command queued successfully,
but because it was never sent to the host, scsi_done() is never called.
Will this cause the command to linger until a SCSI command timeout occurs
while also permanently leaking the dynamically allocated payload?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260727152711.2045-1-tiala@microsoft.com?part=1
prev parent reply other threads:[~2026-07-27 15:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 15:27 [PATCH V2 1/1] x86/VMBus: Confidential VMBus for dynamic DMA transfers Tianyu Lan
2026-07-27 15:39 ` sashiko-bot [this message]
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=20260727153925.221C61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ltykernel@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox