## Executive Summary Mallory is an unprivileged process inside Alice's virtual machine. Alice has attached QEMU's `usb-mtp` device in writable mode and guest device policy allows Mallory to open that emulated USB device. Mallory opens a normal MTP session, declares a five-byte object with `SendObjectInfo`, and ends the following `SendObject` data phase after one byte. QEMU treats the short USB transfer as the end of the data phase and checks the guest-controlled length mismatch with `assert()`, aborting the host QEMU process. This is a loss of availability for Alice's entire VM; it is not a guest-to-host code-execution result, a confidentiality failure, or a requirement for guest kernel privileges. I reviewed QEMU 11.1.50 development source at commit `1df256f5968e`, traced the relevant history, inspected the guest-side PoC, and reviewed preserved KVM/q35/xHCI execution output. The positive run used a fresh isolated target and reached the assertion from UID/GID 65534; an ordinary `OpenSession` control under the same topology completed while QEMU stayed alive. The exact short-transfer assertion first appears in commit `3e096650a64d`, which was released in QEMU 3.1.0. I verified the same assertion in the QEMU 3.1.0 and 11.1.1 source snapshots and in the assessed 11.1.50 development source. Fetched master commit `d43c2d5f89db` also preserves the affected assertion, but was source-reviewed only and was not runtime-tested. I did not identify a fixing commit or a fixed release in the inspected history. This does not claim that every intervening downstream package or maintained branch was individually tested. Classification: CWE-617 (Reachable Assertion); CVSS v3.1 **5.5 Medium** (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`). ## Background ### Host environment - **Operating system:** QEMU ran inside a Debian 12 container on an Ubuntu 24.04.4 LTS host. - **OS/kernel version:** `Linux 6.8.0-134-generic #134-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 26 18:43:11 UTC 2026 x86_64 GNU/Linux` (hostname omitted) - **Architecture:** x86_64 - **QEMU flavor:** `qemu-system-x86_64` - **QEMU version:** 11.1.50 - **Source revision:** `1df256f5968e9f7c3c4533a1383b071c044a36d6` - **QEMU command line:** Run from a directory containing the test kernel as `bzImage`, the prepared PoC initramfs as `initramfs.cpio.gz`, and an empty disposable `mtp-root` directory: ```sh mkdir -p mtp-root qemu-system-x86_64 \ -machine q35,accel=kvm -m 512M \ -nodefaults -display none -serial stdio -monitor none -no-reboot \ -kernel ./bzImage -initrd ./initramfs.cpio.gz \ -append 'console=ttyS0 rdinit=/init scenario=size-assert' \ -device qemu-xhci,id=xhci \ -device usb-mtp,bus=xhci.0,port=1,rootdir="$PWD/mtp-root",readonly=off ``` ### Emulated/Virtualized environment - **Operating system:** Minimal BusyBox Linux initramfs - **OS/kernel version:** Guest `uname -a` was not captured. - **Architecture:** x86_64 - **Machine/accelerator:** `q35` with KVM - **Device/topology:** Emulated xHCI controller with writable `usb-mtp` QEMU can expose a host directory to a guest as a USB Media Transfer Protocol device. The device is read-only by default; writes are enabled only when the operator configures `readonly=off` and the selected host root directory is writable. This report therefore concerns an opt-in writable device configuration: ```text -machine q35,accel=kvm -device qemu-xhci,id=xhci -device usb-mtp,bus=xhci.0,rootdir="$MTP_ROOT",readonly=off ``` QEMU's security policy treats the guest as untrusted in the KVM virtualization use case and lists `q35` as a supported machine type. Its assertion guidance distinguishes guest-root-only self-denial from an assertion that an unprivileged guest account can trigger. The tested topology exercised that latter case: the guest harness made the emulated USB node accessible, then the client dropped to UID/GID 65534 before opening it and submitting the MTP traffic. The expected behavior is that malformed or incomplete MTP data receives a protocol error while QEMU continues running. A guest-supplied object-size mismatch must not terminate the process that owns the whole VM. ## Vulnerability Details ### Description of problem Mallory first sends a valid `OpenSession` command and then `SendObjectInfo` (`0x100c`). In `hw/usb/dev-mtp.c`, `usb_mtp_command()` accepts `SendObjectInfo` only for a writable device and prepares an outgoing-data state. The later `SendObject` command is likewise limited to writable devices and additionally requires the metadata transaction to have set `write_pending`: ```c case CMD_SEND_OBJECT: if (!FLAG_SET(s, MTP_FLAG_WRITABLE)) { usb_mtp_queue_result(s, RES_STORE_READ_ONLY, c->trans, 0, 0, 0, 0); return; } if (!s->write_pending) { usb_mtp_queue_result(s, RES_INVALID_OBJECTINFO, c->trans, 0, 0, 0, 0); return; } s->data_out = usb_mtp_data_alloc(c); return; ``` The assessed `usb_mtp_write_metadata()` then copies the untrusted `ObjectInfo.size` into persistent device state. In the demonstrated request that value is five: ```c s->dataset.filename = filename; s->dataset.format = dataset->format; s->dataset.size = dataset->size; s->write_pending = true; ``` Mallory next sends `SendObject` (`0x100d`), which is accepted because the device is writable and the prior metadata made `write_pending` true. The PoC sends a data container carrying only one object byte. In `usb_mtp_get_data()`, QEMU copies that byte, advances `d->offset` to one, and interprets the 13-byte USB transfer as the end of the data phase because its size is not divisible by 64. It then enforces equality with an assertion instead of returning a protocol result: ```c case CMD_SEND_OBJECT: usb_packet_copy(p, d->data + d->data_offset, dlen); d->offset += dlen; d->data_offset += dlen; if ((p->iov.size % 64) || !p->iov.size) { assert((s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)); ``` For the demonstrated request, `s->dataset.size` is 5 and `d->offset` is 1, so the condition is false and `abort()` terminates QEMU. The route is guest usbfs bulk I/O through the emulated xHCI controller to `usb_mtp_handle_data()`, `usb_mtp_get_data()`, and the assertion. History inspection shows that writable `SendObject` support entered before this particular end-of-transfer check. Commit `3e096650a64d` ("dev-mtp: Add support for \> 4GB file transfers") changed completion detection to rely on a short USB packet and introduced the size assertion. QEMU 3.1.0 is the earliest release snapshot in which I verified this exact assertion. Later refactoring changed the compared accumulator from `d->length` to `d->offset`, but retained the guest-triggerable abort through QEMU 11.1.1 and the assessed 11.1.50 development source. ## Exploitability Analysis The demonstrated primitive is deterministic termination of the QEMU process from an unprivileged guest account. It crosses the intended privilege boundary between Mallory's limited guest process and Alice's VM-wide availability: Mallory does not need guest root or kernel execution after guest device permissions allow access to the emulated MTP node. The following prerequisites were verified or are explicit: - QEMU runs the `q35` machine with KVM, which is within the documented virtualization security model. - A writable `usb-mtp` device is attached. Read-only is the default, so `readonly=off` is a necessary opt-in condition. - Guest device policy allows the unprivileged account to open the emulated MTP device. The validation harness set that permission before dropping to UID/GID 65534. - Mallory can submit ordinary USB bulk transfers through usbfs. No malformed host file, QMP access, QEMU process credential, or guest kernel exploit is used. The ordinary control used the same KVM/q35/xHCI topology, opened the same MTP device as UID/GID 65534, sent a valid `OpenSession`, received a response, printed `MTP_CONTROL_COMPLETED`, and powered down normally. This rules out startup failure, lack of MTP reachability, and the known unrelated KVM startup sanitizer warning as explanations for the crash. The positive sequence sent valid setup traffic followed by the five-versus-one length mismatch and QEMU reported the exact `usb_mtp_get_data()` assertion before aborting. Only availability was demonstrated. The result does not establish host memory disclosure, host data modification beyond normal writable-MTP semantics, arbitrary code execution, VM escape, or impact to other QEMU processes. Host supervision may restart the VM, but that does not prevent the attacker from terminating the running instance again while the vulnerable configuration and guest access remain. ## Proof of Concept Attachment : [usb-mtp-length-assert-poc.zip](/uploads/24af9ad2df854f550e61d7ac65c95154/usb-mtp-length-assert-poc.zip) ### Steps to reproduce 1. Enter the sibling `poc/` directory and run `make` to build the static x86-64 `mtp-size-assert` guest helper. 2. Prepare a minimal BusyBox Linux initramfs as described in `poc/README.md`, installing the helper as `/bin/mtp-size-assert` and the supplied script as `/init`. Place the resulting image beside the guest kernel as `initramfs.cpio.gz` and `bzImage`. 3. Create a new empty `mtp-root` directory and run the complete QEMU command from **Host environment**, first changing the kernel argument to `scenario=control`. Confirm that UID/GID 65534 completes `OpenSession`, QEMU remains alive, and the guest powers down normally. 4. Start a fresh QEMU process with the command exactly as shown, using `scenario=size-assert`. The helper declares a five-byte object, ends `SendObject` after one byte, and the vulnerable QEMU process aborts in `usb_mtp_get_data()`. ### Additional information Reproduction uses the following reviewed files: - `mtp-size-assert.c` implements both the ordinary control and the size-mismatch trigger. - `Makefile` builds a static x86-64 Linux helper suitable for an initramfs. - `init` is a minimal example initramfs entry point that selects `control` or `size-assert` from the kernel command line. - `README.md` gives build and launch instructions. - `observed-output.txt` preserves the relevant output from the KVM validation, with environment-specific local paths omitted. - `proposed-fix.patch` removes the assertion so the existing incomplete-transfer path handles the mismatch. It is a review proposal, not an upstream or end-to-end tested fix. Build the helper from the report directory: ```sh cd poc make ``` Place `mtp-size-assert` and `init` in a Linux initramfs that also provides `/bin/sh`, `mount`, `poweroff`, and the xHCI/usbfs support needed by the guest kernel. The README provides a QEMU command template. Run the control first with `scenario=control`, then use a fresh QEMU process with `scenario=size-assert`. The preserved ordinary control includes: ```text ATTACKER_UID 65534 GID 65534 BULK ep=0x2 requested=16 rc=16 BULK ep=0x81 requested=64 rc=12 MTP_CONTROL_COMPLETED MTP_GUEST_HELPER_RC 0 KVM_GUEST_DONE ``` The positive run includes: ```text ATTACKER_UID 65534 GID 65534 BULK ep=0x2 requested=67 rc=67 BULK ep=0x81 requested=64 rc=24 BULK ep=0x2 requested=12 rc=12 qemu-system-x86_64: ../hw/usb/dev-mtp.c:1816: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed. ``` This PoC intentionally aborts the target QEMU process and may create a partial file in the configured MTP root. Run it only against a disposable VM and an empty disposable host directory. Do not point `rootdir` at valuable data. The client does not attempt code execution or access outside the configured MTP tree. ## Remediation Do not use an assertion to validate the guest-declared object size. A short `SendObject` transfer whose accumulated byte count differs from `ObjectInfo.size` is an untrusted protocol error and must produce an MTP error response while keeping the device and QEMU process alive. The surrounding function already has a graceful incomplete-transfer path in `usb_mtp_write_data()`: when an end-of-transfer write reaches `WRITE_END`, it compares `d->offset` with `s->dataset.size`, queues `RES_INCOMPLETE_TRANSFER`, and closes and clears the write state. A small source-compatible fix is therefore to remove the assertion and let that existing path handle the mismatch. If maintainers prefer rejecting before writing the partial object, the replacement branch must queue `RES_INCOMPLETE_TRANSFER` and perform the same file-descriptor, filename, `dataset.size`, `write_pending`, and `data_out` cleanup without double-freeing the active `MTPData`. Add a qtest regression that: 1. configures writable `usb-mtp` on a supported USB controller; 2. completes `OpenSession` and `SendObjectInfo` with a declared size of five; 3. ends `SendObject` after one byte and verifies an incomplete-transfer result while QEMU remains responsive; 4. repeats with a matching one-byte declaration as the positive protocol control; 5. covers a zero-length termination and the `0xFFFFFFFF` greater-than-4-GiB sentinel so those supported paths are not regressed. Until a fix is available, leaving `usb-mtp` read-only prevents this write path. Where writable MTP is required, restrict guest access to the device node so unprivileged accounts cannot submit raw USB transactions; that reduces reachability but does not repair the device model. ## Summary On a KVM-accelerated `q35` VM with writable `usb-mtp`, an unprivileged guest process that can access the emulated USB node can declare a five-byte MTP object and terminate the data phase after one byte. QEMU checks that untrusted mismatch with an assertion and aborts the whole VM process. The result was observed as UID/GID 65534 with an ordinary same-topology control that stayed alive. The exact short-packet assertion is source-confirmed from QEMU 3.1.0 through QEMU 11.1.1, remains present in the assessed QEMU 11.1.50 development source, and is still present in source at fetched master `d43c2d5f89db`; master was not runtime-tested. No fixed release was identified. The demonstrated impact is availability only. ### AI Disclosure AI-assisted tooling helped prepare this report. I have ran the PoC and verified the report myself.