Re: [PULL v2 09/30] virtio-mmio: fix QUEUE_NUM_MAX

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jul 28, 2026 at 11:40:24AM +0300, Michael Tokarev wrote:
> On 7/27/26 22:19, Michael S. Tsirkin wrote:
> > virtio-mmio reports VIRTQUEUE_MAX_SIZE (1024) as QUEUE_NUM_MAX for every
> > queue, regardless of the size the device passes to virtio_add_queue().
> > 
> > This works by accident because QEMU mostly does not care about the ring
> > size - the guest is the one allocating memory here.  But this changes
> > with in-order vqs where qemu is the one allocating resources.
> > Now, specifying a larger vq than allocated causes an OOB memory access.
> > 
> > To fix:
> > - for new machine types, report the actual max queue size to guest
> > - for old machine types, use a compat property to allocate 1k sized
> >    queues
> > 
> > Fixes: 525d82e323 ("virtio: fix queue size validation against allocated maximum")
> 
> This is actually d530f2dfbd2 in the master branch.
> But his is an interesting case of the Fixes: tag.
> 
> The change it is fixing (this non-existing commit) is in
> the same pull request and comes right NEXT to this fix!
> So we fix something first and introduce it.. later? :)
> 
> It's a fun stuff.

Got some wires crossed here) thanks for noticing.


> But besides this, I wonder what can we do with that for
> the stable series...
> 
> > Fixes: CVE-2026-50626
> > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3882
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Message-ID: <8715acbb9516e67e2a776cda6f9edf105343f788.1784930765.git.mst@redhat.com>
> > Acked-by: Yonggang Luo <luoyonggang@gmail.com>
> > Reported-by: Miku Hatsune <anznu1l@gmail.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ...
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 805148678d..73b4d82b4a 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -41,6 +41,7 @@
> >   #include "hw/arm/smmuv3.h"
> >   GlobalProperty hw_compat_11_0[] = {
> > +    { "virtio-mmio", VIRTIO_QUEUE_SIZE_OVERRIDE, "1024" },
> 
> ..because it is adding a new field into the migration stream,
> which is a problem for stable series.


this is compat not a migration stream, right?
For stable, the value needs to be 1024 for all types.

> Or is it a problem in previous releases?
> 
> Thanks,
> 
> /mjt