Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Miku Hatsune <anznu1l@gmail.com>` * Date: `27 May, 2026` * Message ID: `<CANh+zOtejQKYqg8J4Su=OfDssW6iaiVGDFQZCOs7MdOO5UYWiA@mail.gmail.com>` **NOTE:** the original reporter can not be copied on this issue so cannot view this ticket while it remains marked confidential. If further information is needed about the disclosure, contact the reporter directly. ---- I would like to report a heap buffer overflow vulnerability in QEMU’s virtio subsystem that I was able to reproduce and confirm using AddressSanitizer (ASAN). The issue appears to allow a malicious guest to trigger an out-of-bounds access on the host QEMU process heap through the virtio queue configuration path.The issue requires the in_order feature to be enabled, and I am not entirely certain whether this falls within the intended security boundary. Affected Code ## File: - hw/virtio/virtio.c ## Relevant functions: - virtqueue_ordered_flush() (line 1164) — OOB access trigger - virtio_queue_set_num() (line 2411) — insufficient bounds validation - virtio_add_queue() (line 2575) — initial used_elems allocation ## Vulnerability Summary The issue originates from a mismatch between the allocation size of the used_elems array and the later runtime value of vring.num. During device initialization, virtio_add_queue() allocates used_elems using the initial queue size: ``` vdev->vq[i].used_elems = g_new0(VirtQueueElement, queue_size); ``` In typical configurations, queue_size is 256 entries. However, the guest may later update the queue size through the PCI modern configuration register (CFG + 0x18), which eventually invokes virtio_queue_set_num(). Although virtio_queue_set_num() validates that the requested size is within [0, VIRTQUEUE_MAX_SIZE], it does not verify whether the new value exceeds the size originally allocated for used_elems: ``` void virtio_queue_set_num(VirtIODevice *vdev, int n, int num) { if (!!num != !!vdev->vq[n].vring.num || num > VIRTQUEUE_MAX_SIZE || num < 0) { return; } vdev->vq[n].vring.num = num; } ``` As a result, a guest can enlarge vring.num (e.g. from 256 to 1024) while used_elems remains allocated for only the original number of entries. When the VIRTIO_F_IN_ORDER feature (bit 35) is negotiated, virtqueue_ordered_flush() uses vring.num as the modulus for indexing into used_elems: ``` unsigned int i = vq->used_idx % vq->vring.num; while (vq->used_elems[i].in_order_filled) { ``` Under these conditions, i may exceed the allocated bounds of used_elems, resulting in an out-of-bounds heap access. In addition to the read in virtqueue_ordered_flush(), related paths such as virtqueue_pop() may also write to indices derived from vring.num, potentially turning the issue into a heap out-of-bounds write as well. ## Trigger Conditions The issue can be triggered under the following conditions: 1. The guest negotiates the VIRTIO_F_IN_ORDER feature 2. The guest increases queue_size beyond the original allocation size via PCI modern config space 3. The guest submits more requests than the original queue capacity (e.g. >256 entries) A simplified trigger flow is: 1. Guest writes queue_size = 1024 → virtio_queue_set_num() updates vring.num → used_elems remains allocated for 256 entries 2. Guest submits 300+ requests through the virtqueue 3. Completion handling eventually accesses: used_elems[i] where i >= 256 ## ASAN Confirmation ``` ==56107==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x52800000f914 at pc 0x56a3205ec2ee bp 0x7f2a187f4bd0 sp 0x7f2a187f4bc0 READ of size 1 at 0x52800000f914 thread T0 #0 0x56a3205ec2ed in virtqueue_ordered_flush ../hw/virtio/virtio.c:1164 #1 0x56a3205ec77c in virtqueue_flush ../hw/virtio/virtio.c:1214 #2 0x56a3205ec8e6 in virtqueue_push ../hw/virtio/virtio.c:1227 #3 0x56a31ffc50e4 in virtio_blk_req_complete ../hw/block/virtio-blk.c:67 #4 0x56a31ffc579e in virtio_blk_rw_complete ../hw/block/virtio-blk.c:132 #5 0x56a320e02c94 in blk_aio_complete ../block/block-backend.c:1586 #6 0x56a320e03245 in blk_aio_read_entry ../block/block-backend.c:1641 #7 0x56a321207459 in coroutine_trampoline ../util/coroutine-ucontext.c:175 #8 0x7f2a1de5ef7f (/lib/x86_64-linux-gnu/libc.so.6+0x5ef7f) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) 0x52800000f914 is located 20 bytes after 14336-byte region [0x52800000c100,0x52800000f900) allocated by thread T0 here: #0 0x7f2a1eafd340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x7f2a1e5a8771 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x63771) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3) #2 0x56a3205f6d92 in virtio_add_queue ../hw/virtio/virtio.c:2575 #3 0x56a31ffd0a50 in virtio_blk_device_realize ../hw/block/virtio-blk.c:1812 #4 0x56a3205feb1c in virtio_device_realize ../hw/virtio/virtio.c:4058 #5 0x56a320cc8baf in device_set_realized ../hw/core/qdev.c:514 #6 0x56a320cdec6a in property_set_bool ../qom/object.c:2496 #7 0x56a320cd9bb5 in object_property_set ../qom/object.c:1560 #8 0x56a320ce3be1 in object_property_set_qobject ../qom/qom-qobject.c:28 #9 0x56a320cda14b in object_property_set_bool ../qom/object.c:1630 #10 0x56a320cc77d0 in qdev_realize ../hw/core/qdev.c:277 #11 0x56a32066b907 in virtio_blk_pci_realize ../hw/virtio/virtio-blk-pci.c:63 #12 0x56a3205c2b91 in virtio_pci_realize ../hw/virtio/virtio-pci.c:2345 #13 0x56a3203426ff in pci_qdev_realize ../hw/pci/pci.c:2309 #14 0x56a3205c35ac in virtio_pci_dc_realize ../hw/virtio/virtio-pci.c:2456 #15 0x56a320cc8baf in device_set_realized ../hw/core/qdev.c:514 #16 0x56a320cdec6a in property_set_bool ../qom/object.c:2496 #17 0x56a320cd9bb5 in object_property_set ../qom/object.c:1560 #18 0x56a320ce3be1 in object_property_set_qobject ../qom/qom-qobject.c:28 #19 0x56a320cda14b in object_property_set_bool ../qom/object.c:1630 #20 0x56a320cc77d0 in qdev_realize ../hw/core/qdev.c:277 #21 0x56a320716a4d in qdev_device_add_from_qdict ../system/qdev-monitor.c:740 #22 0x56a320716b5d in qdev_device_add ../system/qdev-monitor.c:758 #23 0x56a3206ac8fc in device_init_func ../system/vl.c:1216 #24 0x56a3211dcc36 in qemu_opts_foreach ../util/qemu-option.c:1148 #25 0x56a3206b4023 in qemu_create_cli_devices ../system/vl.c:2753 #26 0x56a3206b44d8 in qmp_x_exit_preconfig ../system/vl.c:2813 #27 0x56a3206b93c6 in qemu_init ../system/vl.c:3846 #28 0x56a321016216 in main ../system/main.c:71 #29 0x7f2a1de2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/virtio/virtio.c:1164 in virtqueue_ordered_flush Shadow bytes around the buggy address: 0x52800000f680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x52800000f700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x52800000f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x52800000f800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x52800000f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x52800000f900: fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52800000f980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52800000fa00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52800000fa80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52800000fb00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x52800000fb80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==56107==ABORTING `` ## Reproduction I also developed a PoC that reproduces the issue reliably on an ASAN-enabled QEMU build. The PoC: - Attaches a virtio-blk-pci device with in_order=on - Updates queue_size via PCI config space - Submits more requests than the original queue capacity - Triggers the ASAN-detected out-of-bounds access in virtqueue_ordered_flush() The issue is reachable entirely through guest-accessible interfaces and does not require host privileges. I would be happy to provide the PoC and any additional debugging information if needed. [poc-virtio-inorder.py](/uploads/b229e309ca39192579146a6c1396de7d/poc-virtio-inorder.py)