## Host environment - Operating system: Linux - Architecture: x86_64 - QEMU flavor: qemu-system-x86 - QEMU version: 10.1.2 ## Description of problem A guest-triggerable assertion failure exists in QEMU's USB MTP device emulation that can crash the host QEMU process (SIGABRT) without requiring any special build flags (no sanitizer needed). The issue is in the EP_DATA_IN result-handling path of hw/usb/dev-mtp.c. When the MTP responder returns a result with argc \> 0, the total response length is 12 + 4 \* argc bytes (12-byte MTP container header plus 4-byte argument words).\ However, the entry check in this path only validates that the guest-supplied USB transfer buffer is at least 12 bytes: **hw/usb/dev-mtp.c:1858 :**  ``` if (p->iov.size < sizeof(container)) { /* only checks >= 12 */ p->status = USB_RET_STALL; return; } ``` The code then performs two separate usb_packet_copy() calls: **hw/usb/dev-mtp.c:1906-1926 :** ``` } else if (s->result != NULL) { MTPControl *r = s->result; int length = sizeof(container) + r->argc * sizeof(uint32_t); // 12 + 4*argc / ... build container ... / usb_packet_copy(p, &container, sizeof(container)); // first copy: 12 bytes usb_packet_copy(p, &params, length - sizeof(container)); // second copy: 4*argc } ``` The second copy invokes usb_packet_copy() in hw/usb/core.c, which asserts: ``` void usb_packet_copy(USBPacket *p, void *ptr, size_t bytes) { QEMUIOVector *iov = p->combined ? &p->combined->iov : &p->iov; assert(p->actual_length >= 0); assert(p->actual_length + bytes <= iov->size); /* ... */ } ``` When iov.size = 12 (set from guest-controlled qTD TBYTES field via EHCI DMA setup) and argc = 1, the first copy succeeds (actual_length becomes 12), but the second copy needs 4 more bytes (12 + 4 = 16 \> 12), triggering the assertion and aborting QEMU. The guest controls p-\>iov.size completely through the EHCI qTD TBYTES field. This is standard USB HCD emulation design — TBYTES flows through ehci_init_transfer() → usb_packet_map() → p-\>iov.size. A concrete trigger: CMD_OPEN_SESSION returns RES_OK with argc=0 (12 bytes) on the first call, but RES_SESSION_ALREADY_OPEN with argc=1 (16 bytes) on the second call. If the guest submits a BULK IN transfer with only 12 bytes of buffer for the second response, the assertion fires. Affected source paths: ``` hw/usb/dev-mtp.c — MTP EP_DATA_IN result handling hw/usb/core.c — usb_packet_copy() assertion ``` ## Steps to reproduce [usb-mtp-result-test.c](/uploads/d9578cbbd41d3f64c4f7ee8a89c42788/usb-mtp-result-test.c) [usb-mtp-result-normal-test.c](/uploads/dad67c5d977132809e663181ba8594f1/usb-mtp-result-normal-test.c) [meson.build.patch](/uploads/90a6edd04a22b2cbb7599f6da1c204f7/meson.build.patch) 1. C qtest reproducer: ``` cd qemu-10.1.2 mkdir -p build-x86-mtp ./configure --target-list=x86_64-softmmu --enable-debug ninja -C build-x86-mtp qemu-system-x86_64 cp ../usb-mtp_dos/usb-mtp-result-test.c tests/qtest/ cp ../usb-mtp_dos/usb-mtp-result-normal-test.c tests/qtest/ # apply ../usb-mtp_dos/meson.build.patch to tests/qtest/meson.build meson compile -C build-x86-mtp usb-mtp-result-test usb-mtp-result-normal-test export QTEST_QEMU_BINARY=./build-x86-mtp/qemu-system-x86_64 ./build-x86-mtp/tests/qtest/usb-mtp-result-normal-test ./build-x86-mtp/tests/qtest/usb-mtp-result-test ``` Expected Result * usb-mtp-result-normal-test: exits cleanly (ok). * usb-mtp-result-test: aborts QEMU with usb_packet_copy assertion ## Additional information Suggested fix: In hw/usb/dev-mtp.c, validate the full required response length before any copy: ``` size_t need = 12 + (size_t)s->result->argc * 4; if (p->iov.size < need) { p->status = USB_RET_STALL; return; } ``` <!--The line below ensures that proper tags are added to the issue. Please do not remove it.-->