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.
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 <[email protected]>
Message-ID:
<8715acbb9516e67e2a776cda6f9edf105343f788.1784930765.git....@redhat.com>
Acked-by: Yonggang Luo <[email protected]>
Reported-by: Miku Hatsune <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
...
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.
Or is it a problem in previous releases?
Thanks,
/mjt
