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: `11 Apr, 2026` * Message ID: `<0aRgkFdOTJB2uZwCSl9UW6AneASIuWawGqNHay-L4qQ-fwFXksjcRdPTAU17hEcKLGuwxdPkR0zVbPPMfY2NsXnI6uunvXaBNtVEbXr76nE=@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 an undefined behavior vulnerability in QEMU's xHCI USB controller emulation (hw/usb/hcd-xhci.c). The function xhci_init_epctx() at line 1123 performs: ``` epctx->interval = 1 << ((ctx[0] >> 16) & 0xff); ``` ctx[0] is read directly from guest DMA memory (the endpoint context provided by the guest via the xHCI command ring). The shift amount (bits 23:16 of ctx[0]) can be 0–255. Shifting a 32-bit int left by ≥32 is undefined behavior in C (C11 §6.5.7p4). A guest can supply an endpoint context with interval bits = 0xFF to trigger this UB. Affected file: hw/usb/hcd-xhci.c, line 1123 (xhci_init_epctx) QEMU version: 10.2.2 (current stable); all versions since xHCI introduction Commit ID: f8ed81651e61d9c2166df6121ce2af0f44f06b3e Platform: x86_64 (any machine with nec-usb-xhci or qemu-xhci device) Impact: UBSan-detected crash (SIGABRT); potential compiler misoptimization on production builds The issue was confirmed with UndefinedBehaviorSanitizer on qemu-system-x86_64 using the QTest framework. The full UBSan report: ``` hcd-xhci.c:1123:25: runtime error: shift exponent 255 is too large for 32-bit type 'int' #0 xhci_init_epctx hw/usb/hcd-xhci.c:1123 #1 xhci_enable_ep hw/usb/hcd-xhci.c:1144 #2 xhci_configure_slot hw/usb/hcd-xhci.c:2262 #3 xhci_process_commands hw/usb/hcd-xhci.c:2519 #4 xhci_doorbell_write hw/usb/hcd-xhci.c:3164 ``` The trigger requires: 1. A Configure Endpoint command with ep_ctx[0] bits 23:16 = 0xFF 2. The slot must be in SLOT_ADDRESSED state (requires a prior successful Address Device command and an attached USB device) The PoC uses a USB tablet (-device usb-tablet,bus=xhci.0) as the attached device; no guest OS is needed. Suggested fix: clamp the interval exponent before the shift: epctx->interval = 1u << MIN((ctx[0] >> 16) & 0xff, 31u); Three files are attached: 1. SECURITY_REPORT.md — Full report with root cause analysis, reproduction steps, UBSan output, fix suggestion. 2. qtest_poc.py — QTest reproduction script. Build qemu-system-x86_64 with ASan+UBSan, then run: export UBSAN_OPTIONS="halt_on_error=1:abort_on_error=1:print_stacktrace=1" python3 qtest_poc.py ./build-asan/qemu-system-x86_64 ./pc-bios QEMU aborts with UBSan at xhci_init_epctx:1123. 3. unit_test.c — Standalone C proof (no QEMU build needed): gcc -fsanitize=address,undefined -O0 -g -o h5 unit_test.c ./h5 Actual UBSan output: H5/unit_test.c:99:28: runtime error: shift exponent 255 is too large for 32-bit type 'int' This issue was discovered through LLM-assisted source code audit and manually validated with UBSan on real QEMU binaries. Please let me know if you need any additional information. [unit_test.c](/uploads/72e813cdbfd7ffb5e35fb89661084800/unit_test.c) [qtest_poc.py](/uploads/c687e0fd7f0bb54386d2ce97dafc2fef/qtest_poc.py) [SECURITY_REPORT.md](/uploads/f3498fd0addcc905ae08321697451bd7/SECURITY_REPORT.md)