Imported by the "Security Issuer Importer" bot, on behalf of the original reporter who disclosed via qemu-security list: * From: `Feifan Qian <bea1e@proton.me>` * Date: `14 Apr, 2026` * Message ID: `<W2afqCJIxQfkY-67T8zWkE-IOT9oYUpAI9lCB5jmKEQCDv2kkjosPNOnVm0NcucsQzQPTxaE4gb_UONYY_GGXWBYJKjASCP74O6wTTm51j0=@proton.me>` **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 am reporting a use-after-free vulnerability in QEMU's OHCI (USB 1.1) host controller emulation (hw/usb/hcd-ohci.c). The function ohci_service_iso_td() allocates a USBPacket with g_new0(), hands it to usb_handle_packet(), and then unconditionally calls g_free(pkt) at line 751 — even when usb_handle_packet() returns USB_RET_ASYNC. For usb-storage devices, usb_device_flush_ep_queue() at line 750 is a no-op (only usb-host and usb-redir implement the callback), so the pending async operation is not cancelled. The device stores a dangling pointer in s->packet. When the SCSI backend later completes, usb_msd_packet_complete() dereferences the freed memory via usb_packet_complete(dev, s->packet). Affected file: hw/usb/hcd-ohci.c, line 751 (ohci_service_iso_td) QEMU version: 10.2.2 (current stable); all versions since OHCI intro Commit ID: f8ed81651e61d9c2166df6121ce2af0f44f06b3e Platform: x86_64 with pci-ohci + usb-storage Impact: Guest → host heap-use-after-free; potential code execution The QTest PoC uses QEMU's null-co block driver (latency-ns=10s) so the SCSI READ stays pending when the ISO TD fires. The unit test confirms with actual ASan output: ``` ==ERROR: AddressSanitizer: heap-use-after-free on address 0x504000000010 READ of size 4 at 0x504000000010 thread T0 #0 sim_usb_packet_complete H1/unit_test.c:93 #1 main H1/unit_test.c:155 0x504000000010 is located 0 bytes inside of 48-byte region freed by thread T0 here: #1 main H1/unit_test.c:148 previously allocated by thread T0 here: #2 main H1/unit_test.c:111 SUMMARY: AddressSanitizer: heap-use-after-free in sim_usb_packet_complete ``` Three files are attached: 1. SECURITY_REPORT.md — Full report with root cause analysis, reproduction steps (unit test and QTest), ASan output, and suggested fix. 2. unit_test.c — Standalone C proof (no QEMU build needed): gcc -fsanitize=address,undefined -fno-omit-frame-pointer -O0 -g \ -o h1 unit_test.c $(pkg-config --cflags --libs glib-2.0) G_SLICE=always-malloc ./h1 Triggers ASan heap-use-after-free immediately, every run. 3. qtest_poc.py — QTest reproduction script using null-co backend. Build QEMU with ASan, then run: python3 qtest_poc.py ./qemu-system-x86_64 ./pc-bios Sequence: CBW (SCSI READ blocked by null-co) → ISO TD (USB_RET_ASYNC → g_free with dangling s->packet) → clock advance past null-co deadline → usb_msd_packet_complete dereferences freed packet → heap-use-after-free. Suggested fix: replace the unconditional g_free(pkt) with a cancellation before free when USB_RET_ASYNC is returned: if (pkt->status == USB_RET_ASYNC) { usb_cancel_packet(pkt); // removes from ep->queue, cancels async op } g_free(pkt); This issue was discovered through LLM-assisted source code audit of QEMU 10.2.2 and validated with a standalone GLib-based unit test and QTest simulation. Note: this is a separate vulnerability from the eTSEC FCB OOB write (process_tx_fcb in rings.c), also reported separately. Please let me know if you need any additional information. [SECURITY_REPORT.md](/uploads/9960693cd97bd88debccb1cf1ec196d8/SECURITY_REPORT.md) [qtest_poc.py](/uploads/8741fd34bda629c8fec7a57ed2bd16fe/qtest_poc.py) [unit_test.c](/uploads/9a198ff63d56e7bf6e8ff6169b2d108b/unit_test.c)