From: Dongli Zhang <dongli.zhang@oracle.com>
To: sashiko-reviews@lists.linux.dev, virtualization@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 2/2] vhost-scsi: reject invalid max_io_vqs module parameter
Date: Fri, 31 Jul 2026 16:31:23 -0700 [thread overview]
Message-ID: <e09417fb-9d71-49ef-b405-5c52d8e02684@oracle.com> (raw)
In-Reply-To: <20260731222633.15DE01F00AC4@smtp.kernel.org>
+ virtualization@lists.linux.dev
On 2026-07-31 3:26 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Missing READ_ONCE() on module parameter allows compiler rematerialization, leading to TOCTOU array out-of-bounds access.
> --
>
> --- Patch [2]: [PATCH 2/2] vhost-scsi: reject invalid max_io_vqs module parameter ---
> commit 93f3d55f364233d31773cdb70b64bd78dafbf480
> Author: Dongli Zhang <dongli.zhang@oracle.com>
>
> vhost-scsi: reject invalid max_io_vqs module parameter
>
> This commit shifts the validation of the max_io_vqs module parameter from
> device open time to when the parameter is written. It removes the
> bounds-checking code from vhost_scsi_open() and uses a module parameter
> callback to reject invalid sysfs writes instead.
>
>> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
>> index 0c0634eea1443..c138c29ce3dd4 100644
>> --- a/drivers/vhost/scsi.c
>> +++ b/drivers/vhost/scsi.c
> [ ... ]
>> @@ -2273,22 +2286,14 @@ static int vhost_scsi_open(struct inode *inode, struct file *f)
>> struct vhost_scsi_virtqueue *svq;
>> struct vhost_scsi *vs;
>> struct vhost_virtqueue **vqs;
>> - int r = -ENOMEM, i, nvqs = vhost_scsi_max_io_vqs;
>> + int r = -ENOMEM, i, nvqs;
>>
>> vs = kvzalloc_obj(*vs);
>> if (!vs)
>> goto err_vs;
>> vs->inline_sg_cnt = vhost_scsi_inline_sg_cnt;
>>
>> - if (nvqs > VHOST_SCSI_MAX_IO_VQ) {
>> - pr_err("Invalid max_io_vqs of %d. Using %d.\n", nvqs,
>> - VHOST_SCSI_MAX_IO_VQ);
>> - nvqs = VHOST_SCSI_MAX_IO_VQ;
>> - } else if (nvqs == 0) {
>> - pr_err("Invalid max_io_vqs of %d. Using 1.\n", nvqs);
>> - nvqs = 1;
>> - }
>> - nvqs += VHOST_SCSI_VQ_IO;
>> + nvqs = vhost_scsi_max_io_vqs + VHOST_SCSI_VQ_IO;
>
> [Severity: Medium]
> Since vhost_scsi_max_io_vqs is modifiable via sysfs (0644 permissions), could
> the compiler rematerialize nvqs by reloading the global variable from memory
> multiple times in this function?
>
> Without a READ_ONCE(), the compiler is permitted to reload
> vhost_scsi_max_io_vqs instead of spilling nvqs to the stack across the
> subsequent kmalloc_objs() and kvzalloc_objs() calls. If a concurrent sysfs
> write occurs, the reloaded values can differ.
>
> Could this cause the array allocation sizes to be smaller than the nvqs
> value used in the subsequent initialization loop, resulting in an
> out-of-bounds access?
>
> For example, if the compiler decides to reload the variable:
>
> vs->old_inflight = kmalloc_objs(*vs->old_inflight, nvqs, ...);
> // ...
> vs->vqs = kvzalloc_objs(*vs->vqs, nvqs);
> // ...
> for (i = VHOST_SCSI_VQ_IO; i < nvqs; i++) {
> svq = &vs->vqs[i];
>
> Previously, the complex bounds-checking block likely prevented the compiler
> from reloading the variable, but with the check removed, the value is read
> directly. Should READ_ONCE(vhost_scsi_max_io_vqs) be used here?
>
I can make the change below, either in v2 of PATCH 2/2, or as an additional
follow-up patch, depending on whether the maintainer would prefer a v2:
nvqs = READ_ONCE(vhost_scsi_max_io_vqs) + VHOST_SCSI_VQ_IO;
Thank you very much!
Dongli Zhang
next prev parent reply other threads:[~2026-07-31 23:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 22:10 [PATCH 0/2] vhost-scsi: fix max_io_vqs handling Dongli Zhang
2026-07-31 22:10 ` [PATCH 1/2] vhost-scsi: use kvzalloc for vq array allocation Dongli Zhang
2026-07-31 22:24 ` sashiko-bot
2026-07-31 23:23 ` Dongli Zhang
2026-07-31 22:10 ` [PATCH 2/2] vhost-scsi: reject invalid max_io_vqs module parameter Dongli Zhang
2026-07-31 22:26 ` sashiko-bot
2026-07-31 23:31 ` Dongli Zhang [this message]
2026-08-01 0:00 ` Michael S. Tsirkin
2026-08-01 6:59 ` Dongli Zhang
2026-08-01 9:55 ` Michael S. Tsirkin
2026-08-02 6:53 ` Dongli Zhang
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=e09417fb-9d71-49ef-b405-5c52d8e02684@oracle.com \
--to=dongli.zhang@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@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.