## Host environment - Operating system: Linux - OS/kernel version: 6.5.0-104-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 - Architecture: x86_64 - QEMU flavor: qemu-system-x86_64 - QEMU version: v8.2.10 (ASAN build), confirmed on git master (b833716681) - QEMU command line: qemu-system-x86_64 -M q35 -m 256 -display none \ -qmp unix:/tmp/qmp.sock,server,nowait \ -device qemu-xhci,id=xhci \ -device usb-host,vendorid=0x<vid>,productid=0x<pid>,id=usbdev ## Emulated/Virtualized environment - Operating system: N/A (no guest OS required, QMP trigger) - Architecture: x86_64 ## Description of problem I used AI/LLM tools for initial discovery and confirmed the bug manually with ASAN and source analysis. Two bugs in hw/usb/host-libusb.c, both causing heap-use-after-free when a passed-through USB device disconnects from the host: **Bug 1 — leaked USBHostRequest with dangling r->p (ASAN confirmed)** usb_host_handle_control() (line 1524) and usb_host_handle_data() (line 1618) call usb_host_req_alloc(), which inserts the request into s->requests and sets r->p = &xfer->packet. When libusb_submit_transfer() fails, the function returns without freeing r or clearing r->p. The caller (xHCI) completes the transfer with NODEV and frees the XHCITransfer (which embeds the USBPacket r->p points to) via xhci_ep_free_xfer(). The leaked request stays on s->requests with r->p pointing to freed memory. A subsequent usb_host_abort_xfers() -> usb_host_req_abort() reads r->p->state — heap-use-after-free. For comparison, the BULK_STREAMS #else branch at line 1580 does call usb_host_req_free(r) before returning on error. The submit-failure paths at lines 1524/1618 should do the same. **Bug 2 — missing BH cleanup in usb_host_unrealize() (code audit)** usb_host_nodev() lazily creates s->bh_nodev and usb_host_post_load() lazily creates s->bh_postld, but usb_host_unrealize() never calls qemu_bh_delete() on either. If a BH is still pending when unrealize returns, the callback dereferences freed USBHostDevice — UAF. ASAN output (QEMU v8.2.10, -fsanitize=address, real USB device, no LD_PRELOAD helpers): ``` ==2487506==ERROR: AddressSanitizer: heap-use-after-free on address 0x5110000ba224 at pc 0x5578d5a4d19d bp 0x7fffea88e3a0 sp 0x7fffea88e390 READ of size 4 at 0x5110000ba224 thread T0 #0 0x5578d5a4d19c in usb_host_req_abort ../hw/usb/host-libusb.c:503 #1 0x5578d5a4d19c in usb_host_abort_xfers ../hw/usb/host-libusb.c:1078 #2 0x5578d5a4d462 in usb_host_close ../hw/usb/host-libusb.c:1112 #3 0x5578d5a5794c56 in usb_device_unrealize ../hw/usb/bus.c:139 #4 0x5578d5a5794c56 in usb_qdev_unrealize ../hw/usb/bus.c:306 #5 0x5578d5e86921 in device_set_realized ../hw/core/qdev.c:599 #6 0x5578d5e914ed in property_set_bool ../qom/object.c:2305 #7 0x5578d5e99c36 in object_property_set ../qom/object.c:1435 #8 0x5578d5ea0384 in object_property_set_qobject ../qom/qom-qobject.c:28 #9 0x5578d5e9ab49 in object_property_set_bool ../qom/object.c:1504 #10 0x5578d58e4a77 in qdev_unplug ../system/qdev-monitor.c:939 #11 0x5578d621a0ef in qmp_marshal_device_del qapi/qapi-commands-qdev.c:114 #12 0x5578d6259132 in do_qmp_dispatch_bh ../qapi/qmp-dispatch.c:128 #13 0x5578d62a8e1d in aio_bh_call ../util/async.c:169 #14 0x5578d62a9137 in aio_bh_poll ../util/async.c:216 #15 0x5578d627034a in aio_dispatch ../util/aio-posix.c:423 #16 0x5578d62a8181 in aio_ctx_dispatch ../util/async.c:358 0x5110000ba224 is located 100 bytes inside of 256-byte region [0x5110000ba1c0,0x5110000ba2c0) freed by thread T4 here: #0 0x7f46cad10b77 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 #1 0x5578d57edfe5 in xhci_kick_epctx ../hw/usb/hcd-xhci.c:2008 #2 0x5578d57f074f in xhci_doorbell_write ../hw/usb/hcd-xhci.c:3169 #3 0x5578d5d5f33c in memory_region_write_accessor ../system/memory.c:497 #4 0x5578d5d61a8b in access_with_adjusted_size ../system/memory.c:573 #5 0x5578d5d645c5 in memory_region_dispatch_write ../system/memory.c:1528 #6 0x5578d5d78bb8 in flatview_write_continue ../system/physmem.c:2699 #7 0x5578d5d78fa9 in flatview_write ../system/physmem.c:2741 #8 0x5578d5d79276 in subpage_write ../system/physmem.c:2339 #9 0x5578d5d5fc60 in memory_region_write_with_attrs_accessor ../system/memory.c:518 #10 0x5578d5d61a8b in access_with_adjusted_size ../system/memory.c:573 #11 0x5578d5d645c5 in memory_region_dispatch_write ../system/memory.c:1528 #12 0x5578d5e31dde in int_st_mmio_leN ../accel/tcg/cputlb.c:2545 #13 0x5578d5e3211e in do_st_mmio_leN ../accel/tcg/cputlb.c:2581 #14 0x5578d5e3c7f7 in do_st_4 ../accel/tcg/cputlb.c:2758 #15 0x5578d5e3c7f7 in do_st4_mmu ../accel/tcg/cputlb.c:2834 previously allocated by thread T4 here: #0 0x7f46cad11097 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7f46ca489ef0 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ef0) #2 0x5578d57f074f in xhci_doorbell_write ../hw/usb/hcd-xhci.c:3169 #3 0x5578d5d5f33c in memory_region_write_accessor ../system/memory.c:497 #4 0x5578d5d61a8b in access_with_adjusted_size ../system/memory.c:573 #5 0x5578d5d645c5 in memory_region_dispatch_write ../system/memory.c:1528 #6 0x5578d5d78bb8 in flatview_write_continue ../system/physmem.c:2699 #7 0x5578d5d78fa9 in flatview_write ../system/physmem.c:2741 #8 0x5578d5d79276 in subpage_write ../system/physmem.c:2339 #9 0x5578d5d5fc60 in memory_region_write_with_attrs_accessor ../system/memory.c:518 #10 0x5578d5d61a8b in access_with_adjusted_size ../system/memory.c:573 #11 0x5578d5d645c5 in memory_region_dispatch_write ../system/memory.c:1528 #12 0x5578d5e31dde in int_st_mmio_leN ../accel/tcg/cputlb.c:2545 #13 0x5578d5e3211e in do_st_mmio_leN ../accel/tcg/cputlb.c:2581 #14 0x5578d5e3c7f7 in do_st_4 ../accel/tcg/cputlb.c:2758 #15 0x5578d5e3c7f7 in do_st4_mmu ../accel/tcg/cputlb.c:2834 Thread T4 created by T0 here: #0 0x7f46cacb4d55 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216 #1 0x5578d627b1d1 in qemu_thread_create ../util/qemu-thread-posix.c:581 #2 0x5578d5e70184 in mttcg_start_vcpu_thread ../accel/tcg/tcg-accel-ops-mttcg.c:148 #3 0x5578d58d74af in qemu_init_vcpu ../system/cpus.c:649 #4 0x5578d5b5b055 in x86_cpu_realizefn ../target/i386/cpu.c:7433 #5 0x5578d5e86c22 in device_set_realized ../hw/core/qdev.c:510 #6 0x5578d5e914ed in property_set_bool ../qom/object.c:2305 ``` The freed-by stack shows the XHCITransfer (which embeds the USBPacket) was freed by xhci_kick_epctx on the vCPU thread (T4), triggered by guest MMIO write to the xHCI doorbell register. The READ crash is on the main thread (T0) via QMP device_del -> unrealize -> close -> abort_xfers -> req_abort, which reads r->p->state on the already-freed USBPacket. This is a cross-thread UAF. A guest with access to a passed-through USB device triggers this by causing the host-side device to disconnect (physical unplug, authorized=0, or bind/unbind race) then issuing device_del. The disconnect causes libusb_submit_transfer to fail, leaking the request. The subsequent device_del cleanup reads the dangling pointer. Confirmed impact: denial of service (QEMU crash). Theoretical: arbitrary code execution if the freed heap region can be repurposed and controlled by the guest. ## Steps to reproduce 1. Build QEMU with `-fsanitize=address -fno-omit-frame-pointer` 2. Start QEMU with a USB device passed through: ``` qemu-system-x86_64 -M q35 -m 256 -display none \ -qmp unix:/tmp/qmp.sock,server,nowait \ -device qemu-xhci,id=xhci \ -device usb-host,vendorid=0x<vid>,productid=0x<pid>,id=usbdev ``` 3. Deauthorize the USB device from the host (simulates physical disconnect): ``` echo 0 > /sys/bus/usb/devices/<devpath>/authorized ``` 4. Immediately issue `device_del` via QMP: ```python {"execute": "qmp_capabilities"} {"execute": "device_del", "arguments": {"id": "usbdev"}} ``` 5. ASAN reports heap-use-after-free in `usb_host_req_abort` [usb_host_uaf_asan.py](/uploads/146ed9065ab581570098a8b58f5c1caf/usb_host_uaf_asan.py)