Guest-controlled xHCI endpoint type confusion triggers QEMU assertion failure
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:
28 May, 2026 - Message ID:
<cX2MXhGFT28u172Wb_3fZ--1wGoYRLZjulNfvgvVA_LuBip2S066zxcywt7XX51Ds0g-nSm8chy3NKbRr5QZEDa3SiThyJgs_l9irxqOEgk=@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.
NOTE: this disclosure includes a report.md file which provides a markdown formatted version of the disclosure which may include more information that this bug description.
I'm writing to report a security vulnerability in QEMU's xHCI USB controller emulation. The issue allows a malicious guest that can program the emulated xHCI controller to configure a real HID interrupt IN endpoint as an isochronous endpoint and then trigger a host-side QEMU assertion failure. This bug was discovered through AI-assisted static code auditing and passed human validation before disclosure.
The issue was reproduced on QEMU 11.0.50 (v11.0.0-1119-g3f129ea545) in the nec-usb-xhci device model with usb-kbd attached. The affected code is in hw/usb/hcd-xhci.c, with the trigger depending on normal HID NAK behavior in hw/usb/dev-hid.c. I have not determined the full historical version range.
This should be treated as a security issue under QEMU's virtualization security model because the guest and emulated-device inputs are untrusted in supported virtualization configurations such as x86_64 q35 with a hardware accelerator. The bug lets guest-controlled xHCI MMIO, DMA input contexts, and transfer rings violate an internal endpoint-type invariant and terminate the host QEMU process.
The demonstrated impact is denial of service: QEMU exits with SIGABRT after reaching an assertion in xhci_kick_epctx. I rate this as CVSS v3.1 AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H, score 5.8 Medium, because exploitation requires privileged guest-side code capable of programming xHCI state but causes availability loss in the host QEMU process. No confidentiality or integrity impact was demonstrated.
A detailed technical report with full reproduction steps and a minimal proof of concept is attached as disclosure.zip. The PoC uses qtest only to deterministically act as privileged guest-side code against the real QEMU nec-usb-xhci and usb-kbd device models. The reproduced evidence includes QEMU exit code -6, the assertion text at hw/usb/hcd-xhci.c:1915, and xHCI trace entries showing the isochronous TRB, retained NAK, and retry path.
Please let me know if you need any additional details or would like to coordinate a disclosure timeline. I can help validate candidate fixes against the attached proof of concept.