Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Jia Jia <physicalmtea@gmail.com>` * Date: `13 Jun, 2026` * Message ID: `<20260613084222.172256-1-physicalmtea@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 found a virtio-pmem UAF bug. This was first hit by fuzzing and then reproduced with a qtest testcase. With a virtio-pmem-pci device backed by a memory-backend-file, a guest can submit a virtio-pmem flush request and then eject the same PCI slot through the guest-visible ACPI PCI hotplug I/O register. The pending thread-pool completion can then run after virtio-pmem queue teardown and enter the completion path with a freed virtqueue. The reproduced trigger uses the packed virtqueue path, with packed=on, not the split-ring path. The guest-side request sequence is: VIRTIO_PMEM_REQ_TYPE_FLUSH virtqueue notify ACPI PCI eject register write for the virtio-pmem slot ## Example device configuration: -object memory-backend-file,id=pmem0,share=on,mem-path=/tmp/virtio-pmem-data.img,size=512M -device virtio-pmem-pci,id=vpmem0,memdev=pmem0,disable-legacy=on,packed=on,addr=04.0 ## Runtime evidence: /tmp/hv-pmem-flush-acpi-eject-kvm-dirty-20260613-142606 ## Tested QEMU: /home/jia/qemu-master/build-x86_64-asan-klaus/qemu-system-x86_64 qemu.git HEAD 81cc5f39aa3042e9c0b2ea772b42a2c8b1488e76 ## Runtime result: qemu.exitcode = 134 qmp-hotplug.log size = 0 The generated qemu.cmd contains: -accel kvm -cpu host -smp 2 -monitor none -device virtio-pmem-pci,id=vpmem0,memdev=pmem0,disable-legacy=on,packed=on,addr=04.0 The generated qemu.cmd does not contain: -qmp ASAN reports a heap-use-after-free in virtqueue_unmap_sg(): ==160518==ERROR: AddressSanitizer: heap-use-after-free on address 0x7562bab59860 READ of size 8 at 0x7562bab59860 thread T0 #0 virtqueue_unmap_sg ../hw/virtio/virtio.c:853 #1 virtqueue_fill ../hw/virtio/virtio.c:1072 #2 virtqueue_push ../hw/virtio/virtio.c:1226 #3 done_cb ../hw/virtio/virtio-pmem.c:61 #4 thread_pool_completion_bh ../util/thread-pool.c:202 #5 aio_bh_poll ../util/async.c:220 #6 aio_dispatch ../util/aio-posix.c:390 #7 aio_ctx_dispatch ../util/async.c:365 #8 g_main_context_dispatch #9 glib_pollfds_poll ../util/main-loop.c:290 #10 os_host_main_loop_wait ../util/main-loop.c:313 #11 main_loop_wait ../util/main-loop.c:592 #12 qemu_main_loop ../system/runstate.c:950 #13 qemu_default_main ../system/main.c:50 #14 main ../system/main.c:93 freed by thread T1 here: #0 __interceptor_free #1 virtio_device_free_virtqueues ../hw/virtio/virtio.c:4114 #2 virtio_device_instance_finalize ../hw/virtio/virtio.c:4121 #3 object_deinit ../qom/object.c:655 #4 object_finalize ../qom/object.c:669 #5 object_unref ../qom/object.c:1336 #6 bus_free_bus_child ../hw/core/qdev.c:55 #7 call_rcu_thread ../util/rcu.c:324 previously allocated by thread T0 here: #0 __interceptor_calloc #1 g_malloc0 #2 virtio_init ../hw/virtio/virtio.c:3588 #3 virtio_pmem_realize ../hw/virtio/virtio-pmem.c:123 #4 virtio_device_realize ../hw/virtio/virtio.c:4058 #5 device_set_realized ../hw/core/qdev.c:514 #6 virtio_pci_realize ../hw/virtio/virtio-pci.c:2345 SUMMARY: AddressSanitizer: heap-use-after-free ../hw/virtio/virtio.c:853 in virtqueue_unmap_sg The freed object is the virtqueue array allocated by virtio_init() and freed during device finalization. The pending completion still reaches it through req_data->pmem->rq_vq. hw/virtio/virtio-pmem.c stores borrowed pointers to the virtio-pmem device and its request queue in each async flush request: req_data->pmem = pmem; req_data->vdev = vdev; thread_pool_submit_aio(worker_cb, req_data, done_cb, req_data); The completion callback later uses those pointers: virtqueue_push(req_data->pmem->rq_vq, &req_data->elem, len); virtio_notify((VirtIODevice *)req_data->pmem, req_data->pmem->rq_vq); The unrealize path tears down the queue without first draining pending thread-pool flush completions: host_memory_backend_set_mapped(pmem->memdev, false); virtio_delete_queue(pmem->rq_vq); virtio_cleanup(vdev); If guest-side ACPI PCI eject tears down the device while a flush worker is still pending, done_cb() can run after virtio_cleanup() has freed the virtqueue array. Duplicate check --------------- Checked upstream git history for hw/virtio/virtio-pmem.c: git log --all --grep='virtio-pmem' --grep='pmem' --grep='thread_pool' \ --grep='use-after-free' --grep='UAF' --regexp-ignore-case \ -- hw/virtio/virtio-pmem.c Relevant history found: virtio-pmem: ignore empty queue notifications thread-pool: avoid passing the pool parameter every time virtio-pmem: fix virtio_pmem_resp assign problem hw: virtio-pmem: detach the element fromt the virtqueue when error occurs virtio-pmem: do delete rq_vq in virtio_pmem_unrealize virtio-pmem: add virtio device I did not find a commit that drains or cancels pending virtio-pmem flush requests before queue teardown. Checked current upstream master source on 2026-06-13: https://gitlab.com/qemu-project/qemu/-/raw/master/hw/virtio/virtio-pmem.c https://gitlab.com/qemu-project/qemu/-/raw/master/include/hw/virtio/virtio-pmem.h The current master source still has done_cb() using req_data->pmem->rq_vq and virtio_pmem_unrealize() deleting the queue without draining pending flushes. Patchwork qemu-devel searches: https://patchwork.kernel.org/project/qemu-devel/list/?q=virtio-pmem%20done_cb%20thread_pool_submit_aio&archive=both https://patchwork.kernel.org/project/qemu-devel/list/?q=virtio_pmem_unrealize%20thread_pool_submit_aio&archive=both https://patchwork.kernel.org/project/qemu-devel/list/?q=virtio-pmem%20use-after-free&archive=both https://patchwork.kernel.org/project/qemu-devel/list/?q=virtqueue_unmap_sg%20virtio-pmem&archive=both All four returned: No patches to display GitLab issue/MR searches: virtio-pmem done_cb virtio-pmem thread_pool_submit_aio virtio_pmem_unrealize thread_pool_submit_aio virtqueue_unmap_sg virtio-pmem No matching issue or merge request was found. Related but different public items: https://gitlab.com/qemu-project/qemu/-/work_items/1298 virtio-pmem missing request data on microvm. This is not a UAF and not the pending flush completion path. https://gitlab.com/qemu-project/qemu/-/work_items/2440 virtio-net failover use-after-free during monitor device_add error handling. This is a different device and a different trigger. Local reports checked: out-patches/ local virtio bug notes Local notes already contained older virtio-rng and virtio-crypto hotunplug reports that depend on management hot-unplug or backend stimulus. They are not this virtio-pmem guest flush completion issue. Minimal fix ----------- Tracking submitted flush AIOCBs and draining them before reset or unrealize fixes this lifetime issue. During drain, completed requests are detached instead of pushed back to a device that is being reset or unrealized. This patch was tested locally: git diff --check -- hw/virtio/virtio-pmem.c include/hw/virtio/virtio-pmem.h ninja -C /home/jia/qemu-master/build-x86_64-asan-klaus qemu-system-x86_64 Fixed-run artifact: /tmp/hv-pmem-flush-acpi-eject-kvm-fixed-20260613-144046 Fixed-run result: qemu.exitcode = 0 qmp-hotplug.log size = 0 qemu.cmd contains -accel kvm qemu.cmd does not contain -qmp guest-serial.log contains request=pmem-flush and post-notify-acpi-eject qemu-host.log has no AddressSanitizer UAF The temporary fix patch was then reverted and the local ASAN QEMU binary was rebuilt back to the unpatched state for later testing. Patch: ``` diff --git a/hw/virtio/virtio-pmem.c b/hw/virtio/virtio-pmem.c index c3b3299c9c..138e550406 100644 --- a/hw/virtio/virtio-pmem.c +++ b/hw/virtio/virtio-pmem.c @@ -21,18 +21,22 @@ #include "hw/virtio/virtio-access.h" #include "standard-headers/linux/virtio_ids.h" #include "standard-headers/linux/virtio_pmem.h" +#include "block/block-global-state.h" #include "system/hostmem.h" #include "block/thread-pool.h" #include "trace.h" -typedef struct VirtIODeviceRequest { +struct VirtIODeviceRequest { VirtQueueElement elem; int fd; VirtIOPMEM *pmem; VirtIODevice *vdev; + BlockAIOCB *aiocb; + bool discard_response; + QTAILQ_ENTRY(VirtIODeviceRequest) node; struct virtio_pmem_req req; struct virtio_pmem_resp resp; -} VirtIODeviceRequest; +}; static int worker_cb(void *opaque) { @@ -54,16 +58,38 @@ static int worker_cb(void *opaque) static void done_cb(void *opaque, int ret) { VirtIODeviceRequest *req_data = opaque; - int len = iov_from_buf(req_data->elem.in_sg, req_data->elem.in_num, 0, - &req_data->resp, sizeof(struct virtio_pmem_resp)); + + QTAILQ_REMOVE(&req_data->pmem->pending_requests, req_data, node); + req_data->aiocb = NULL; /* Callbacks are serialized, so no need to use atomic ops. */ - virtqueue_push(req_data->pmem->rq_vq, &req_data->elem, len); - virtio_notify((VirtIODevice *)req_data->pmem, req_data->pmem->rq_vq); - trace_virtio_pmem_response(); + if (req_data->discard_response || ret == -ECANCELED) { + virtqueue_detach_element(req_data->pmem->rq_vq, &req_data->elem, 0); + } else { + int len = iov_from_buf(req_data->elem.in_sg, req_data->elem.in_num, 0, + &req_data->resp, + sizeof(struct virtio_pmem_resp)); + + virtqueue_push(req_data->pmem->rq_vq, &req_data->elem, len); + virtio_notify((VirtIODevice *)req_data->pmem, req_data->pmem->rq_vq); + trace_virtio_pmem_response(); + } g_free(req_data); } +static void virtio_pmem_drain_flushes(VirtIOPMEM *pmem) +{ + VirtIODeviceRequest *req_data; + + QTAILQ_FOREACH(req_data, &pmem->pending_requests, node) { + req_data->discard_response = true; + } + + while ((req_data = QTAILQ_FIRST(&pmem->pending_requests)) != NULL) { + bdrv_aio_cancel(req_data->aiocb); + } +} + static void virtio_pmem_flush(VirtIODevice *vdev, VirtQueue *vq) { VirtIODeviceRequest *req_data; @@ -85,7 +111,11 @@ static void virtio_pmem_flush(VirtIODevice *vdev, VirtQueue *vq) req_data->fd = memory_region_get_fd(&backend->mr); req_data->pmem = pmem; req_data->vdev = vdev; - thread_pool_submit_aio(worker_cb, req_data, done_cb, req_data); + req_data->aiocb = NULL; + req_data->discard_response = false; + + QTAILQ_INSERT_TAIL(&pmem->pending_requests, req_data, node); + req_data->aiocb = thread_pool_submit_aio(worker_cb, req_data, done_cb, req_data); } static void virtio_pmem_get_config(VirtIODevice *vdev, uint8_t *config) @@ -121,14 +151,21 @@ static void virtio_pmem_realize(DeviceState *dev, Error **errp) host_memory_backend_set_mapped(pmem->memdev, true); virtio_init(vdev, VIRTIO_ID_PMEM, sizeof(struct virtio_pmem_config)); + QTAILQ_INIT(&pmem->pending_requests); pmem->rq_vq = virtio_add_queue(vdev, 128, virtio_pmem_flush); } +static void virtio_pmem_reset(VirtIODevice *vdev) +{ + virtio_pmem_drain_flushes(VIRTIO_PMEM(vdev)); +} + static void virtio_pmem_unrealize(DeviceState *dev) { VirtIODevice *vdev = VIRTIO_DEVICE(dev); VirtIOPMEM *pmem = VIRTIO_PMEM(dev); + virtio_pmem_drain_flushes(pmem); host_memory_backend_set_mapped(pmem->memdev, false); virtio_delete_queue(pmem->rq_vq); virtio_cleanup(vdev); @@ -171,6 +208,7 @@ static void virtio_pmem_class_init(ObjectClass *klass, const void *data) vdc->unrealize = virtio_pmem_unrealize; vdc->get_config = virtio_pmem_get_config; vdc->get_features = virtio_pmem_get_features; + vdc->reset = virtio_pmem_reset; vpc->fill_device_info = virtio_pmem_fill_device_info; vpc->get_memory_region = virtio_pmem_get_memory_region; diff --git a/include/hw/virtio/virtio-pmem.h b/include/hw/virtio/virtio-pmem.h index 9cce600d0b..b83e33c68d 100644 --- a/include/hw/virtio/virtio-pmem.h +++ b/include/hw/virtio/virtio-pmem.h @@ -15,6 +15,7 @@ #define HW_VIRTIO_PMEM_H #include "hw/virtio/virtio.h" +#include "qemu/queue.h" #include "qapi/qapi-types-machine.h" #include "qom/object.h" @@ -26,10 +27,13 @@ OBJECT_DECLARE_TYPE(VirtIOPMEM, VirtIOPMEMClass, #define VIRTIO_PMEM_ADDR_PROP "memaddr" #define VIRTIO_PMEM_MEMDEV_PROP "memdev" +typedef struct VirtIODeviceRequest VirtIODeviceRequest; + struct VirtIOPMEM { VirtIODevice parent_obj; VirtQueue *rq_vq; + QTAILQ_HEAD(, VirtIODeviceRequest) pending_requests; uint64_t start; HostMemoryBackend *memdev; }; ```