AI/LLM-assisted source search was used during discovery and report preparation. The source paths, guest trigger, crash stacks, memory addresses, release impact, and negative controls below were manually validated on local builds. ## Host environment - Operating system: macOS 26.5.1 (25F80) - OS/kernel version: Darwin 25.5.0 - Architecture: arm64, Apple M4 Pro - QEMU flavor: qemu-system-aarch64 with HVF - QEMU versions: - current development commit `b9e9a55f9950b78ef4c940d0599409c614f36766` (QEMU 11.0.90, v11.1.0-rc0-53-gb9e9a55f995) - released Homebrew QEMU 10.0.3 - Relevant QEMU configuration: ```text -object iothread,id=io0 -device pcie-root-port,id=rp0,bus=pcie.0,chassis=1 -device virtio-balloon-pci,id=vballoon,bus=rp0,free-page-hint=on,in_order=on,iothread=io0 ``` Both `free-page-hint` and `in_order` are disabled by default. After an administrator selects this supported configuration, however, the trigger is entirely guest-controlled; no QMP `device_del` is used. ## Emulated/Virtualized environment - Operating system: Alpine Linux 3.24.1 minirootfs - OS/kernel version: Linux 6.18.35-0-virt - Architecture: aarch64 ## Description of problem A guest can schedule the virtio-balloon free-page-hint bottom half on a configured IOThread, then power off the parent PCIe slot from guest PCI configuration space while that callback is processing the queue. The guest PCIe Slot Control write synchronously unrealizes the balloon device on the HVF vCPU thread. `virtio_balloon_device_unrealize()` calls `qemu_bh_delete(s->free_page_bh)`, but BH deletion is asynchronous and does not wait for a callback already running in another AioContext. Teardown then immediately calls `virtio_delete_queue()`, which frees `vq->used_elems` and stores NULL while the IOThread continues through `virtqueue_pop()` / `virtqueue_push()`. With `VIRTIO_F_IN_ORDER` negotiated, both the pop and completion paths access `used_elems`. This creates a real cross-thread use-after-free. Guard Malloc caught the IOThread writing at `0x44c764508` while the HVF vCPU thread was freeing the allocation at base `0x44c764000`: ```text 0x44c764508 - 0x44c764000 = 0x508 = 1288 = 23 * 56 ``` `56` is the runtime size of `VirtQueueElement`; the address is exactly element 23 in the concurrently freed `used_elems` array. ### Trigger and privilege boundary The reproducer is a freestanding guest-root helper that unbinds the normal virtio driver and directly programs the PCI function and virtqueue. It therefore requires guest root or equivalent PCI device-programming authority. The helper performs the PCIe Slot Control power transition itself. The complete tested attack records `QMP_DEVICE_DEL_SENT=0`. Thus the dangerous lifetime transition does not require a host management action after VM launch. The confirmed impact is a guest-triggered QEMU process crash and a host-side UAF read/write. Code execution or VM escape is not claimed. ### Root-cause confirmation 1. `virtio_balloon_handle_free_page_vq()` schedules a raw `VirtIOBalloon *` callback on the configured IOThread: ```c static void virtio_balloon_handle_free_page_vq(VirtIODevice *vdev, VirtQueue *vq) { VirtIOBalloon *s = VIRTIO_BALLOON(vdev); qemu_bh_schedule(s->free_page_bh); } ``` The BH repeatedly calls `virtqueue_pop()` and `virtqueue_push()` on `s->free_page_vq`. 2. With `VIRTIO_F_IN_ORDER`, `virtqueue_split_pop()` stores queue bookkeeping in the queue-owned array: ```c idx = (vq->last_avail_idx - 1) % vq->vring.num; vq->used_elems[idx].index = elem->index; vq->used_elems[idx].len = elem->len; vq->used_elems[idx].ndescs = elem->ndescs; ``` 3. The guest Slot Control write follows this path: ```text guest PCI config write -> pcie_cap_slot_write_config() -> pcie_cap_slot_do_unplug() -> pcie_unplug_device() -> pcie_cap_slot_unplug_cb() -> qdev_unrealize(vballoon) -> virtio_balloon_device_unrealize() ``` 4. Unrealize requests asynchronous BH deletion and then destroys the queue: ```c qemu_bh_delete(s->free_page_bh); ... virtio_delete_queue(s->free_page_vq); ``` `qemu_bh_delete()` only enqueues `BH_DELETED`; it is not a synchronization barrier. `virtio_delete_queue()` then executes: ```c vq->vring.num = 0; vq->handle_output = NULL; g_free(vq->used_elems); vq->used_elems = NULL; ``` The existing `free_page_lock` does not prevent this interleaving. In the reproducer `free_page_hint_status` is `FREE_PAGE_HINT_S_STOP`, so `virtio_balloon_free_page_stop()` skips the mutex. ### Confirmed interleaving ```text HVF vCPU / guest IOThread io0 ----------------------------------- --------------------------------- queue kick qemu_bh_schedule(free_page_bh) ---> virtio_ballloon_get_free_page_hints() virtqueue_pop()/push() Slot Control: power on -> off qdev_unrealize(vballoon) qemu_bh_delete() [async only] virtio_delete_queue() g_free(vq->used_elems) <--> next pop/push accesses used_elems vq->used_elems = NULL SIGSEGV in QEMU host process ``` ## Steps to reproduce 1. Build current QEMU master for `aarch64-softmmu` with HVF and debug symbols. 2. Boot the guest with the IOThread/root-port/virtio-balloon configuration shown above. 3. In the guest, run the helper that: - unbinds the normal guest virtio driver; - negotiates `FREE_PAGE_HINT`, indirect descriptors, and `IN_ORDER`; - disables `EVENT_IDX`, `NOTIFY_ON_EMPTY`, and legacy interrupts; - submits 256 valid queue heads, each backed by a valid 256-entry indirect table; - waits for the IOThread to start processing; - writes the parent root port's PCIe Slot Control register to power off the slot. 4. Observe QEMU exit with SIGSEGV. The controller is used only for status observation and never sends `device_del`. Example retained attack result: ```text MODE=attack ACCELERATOR=hvf IN_ORDER=1 QMP_DEVICE_DEL_SENT=0 QEMU_ALIVE_AFTER_5S=0 QEMU_EXIT_STATUS=139 PCIE_POWER_OFF_TRANSITIONS=1 VIRTQUEUE_POPS=30 ``` The released QEMU 10.0.3 binary also exits 139 without Guard Malloc. Its crash reaches `virtqueue_fill()` / `virtqueue_push()` from `virtio_ballloon_get_free_page_hints()`; the fault address `0x8f8 = 41 * 56` is again the indexed `used_elems` access. ## Dynamic evidence and negative controls | Test | Queue batch | Guest eject | IN_ORDER | Result | |---|---:|---:|---:|---| | full attack, Guard Malloc | yes | yes | on | QEMU SIGSEGV; concurrent free/write proven | | full attack, ordinary allocator | yes | yes | on | QEMU SIGSEGV, 2/2 runs | | released QEMU 10.0.3 | yes | yes | on | QEMU SIGSEGV | | arm only | yes | no | on | QEMU alive; 256 completions | | eject only | no | yes | on | QEMU alive | | full attack without IN_ORDER | yes | yes | off | QEMU alive | Only the full queue-processing plus guest-eject plus `IN_ORDER` combination faults. The no-IN_ORDER control still reaches the teardown race and PCIe power transition but does not access `used_elems`. ### Source-level affected range The ordered `used_elems` implementation entered QEMU in commits `844619147c5110f335cbbbad51cda6a898c7ef33` and `0b0bb34f342f04ab8255a64edb7c6aec7105dc94`, both contained in QEMU v9.1.0. Dynamic reproduction was performed on QEMU 10.0.3 and the development commit listed above. ## Suggested fix Teardown must synchronously quiesce the free-page BH's AioContext before freeing virtqueue or device state. A robust sequence should: 1. prevent new free-page queue work from being scheduled; 2. request BH deletion/cancellation; 3. execute a synchronous barrier in the balloon IOThread's AioContext and wait for any running callback to return; 4. only then unref the IOThread, remove the notifier, and call `virtio_delete_queue()`. Taking only `free_page_lock` in unrealize is not sufficient because the BH's loop and notification tail also operate outside that mutex. Keeping a QOM reference alone is likewise insufficient because `used_elems` is independently freed during queue teardown. ## Attachments - [virtio-balloon-iothread-poc.tar.gz](/uploads/89e7bbb9182e59ee62222dbad798e295/virtio-balloon-iothread-poc.tar.gz) — reproducer launcher, guest helper source, and attack/control binaries. - [virtio-balloon-iothread-evidence.tar.gz](/uploads/c58647a7060fdb6e01c6c452dea74b2b/virtio-balloon-iothread-evidence.tar.gz) — detailed report, Guard Malloc crash, released-QEMU crash, ordinary-allocator crash, and negative-control results.