# Summary I was reviewing the recent commits and looking for interesting fixes/features. As I learn a bit more of the xhci component and re-entrancy, I stumbled upon this somewhat familiar bug pattern. After manually tracing the execution flow, I started having my suspicion and so I used AI to build tests and PoC(s) for a quick sanity check. It turns out there's indeed a sneaky reentrancy issue that can cause UAF again. An unprivileged guest can trigger a heap use-after-free **read** in QEMU's xHCI controller on current master (81ce3a8773). It reproduces on a q35 machine with either `qemu-xhci` or `nec-usb-xhci`. No host-side actor is needed. Default device option are sufficient to reproduce the UAF. I think this is the **residual of CVE-2026-17588 fix** (relative to the fix's _coverage_, not the vulnerability). This is actually a separate path that we all overlooked. The bug trigger has its own entry points and its own re-entry vector, even though the stack trace from asan is very simiar to what we have in #4195. Details in the sections below. CVE-2026-17588 has 2 fixes ([work_items/3926](https://gitlab.com/qemu-project/qemu/-/work_items/3926) + [work_items/4195](https://gitlab.com/qemu-project/qemu/-/work_items/4195)), both of which are ancestors of the tree tested here: - `f91b0544fe` "hw/usb/hcd-xhci: Set reentrancy guard in timer functions (CVE-2026-17588)" — engages `mem_reentrancy_guard` in `xhci_mfwrap_timer()` and `xhci_ep_kick_timer()`. - `89e653b773` "hw/usb/hcd-xhci: Limit DMA transfers to plain memory" — adds `.memory = true` to three xHCI DMA write sites so the event ring can no longer be aimed at MMIO. Neither closes this path, for two structural reasons: 1. **`xhci_complete()` (`hw/usb/hcd-xhci.c:3284`) and `xhci_wakeup_endpoint()` (`:3343`) still run without the re-entrancy guard.** They are the async-USB-completion and endpoint-wakeup callbacks, reached from outside any MMIO handler. 2. **`.memory = true` cannot reach the sink used here.** The re-entrant write is not a DMA descriptor write; it is the **MSI-X message write** in this case. `msix_notify()` -\> `msi_send_message()` -\> `pci_msi_trigger()` (`hw/pci/pci.c:449-467`) issues `address_space_stl_le(&dev->bus_master_as, msg.address, msg.data, attrs, NULL)` with `MemTxAttrs attrs = {}`, and the `address_space_st*` family never calls `flatview_access_allowed()`. The guest programs MSI-X vector 0's message address to point at the xHCI **doorbell array**, which lives in the same `MemoryRegion` as the MSI-X table: both are offsets into the one `s->xhci.mem` - the table at `OFF_MSIX_TABLE 0x3000` (`hw/usb/hcd-xhci-pci.c:35`, passed to `msix_init()` at `hw/usb/hcd-xhci-pci.c:175-179`), the doorbells at `OFF_DOORBELL 0x2000` (`hw/usb/hcd-xhci.c:54`, added as a subregion at `hw/usb/hcd-xhci.c:3452`). Raising an interrupt therefore writes doorbell 0, which runs `xhci_process_commands()`, which executes a `CR_DISABLE_SLOT` the guest planted on the command ring, which frees the `XHCITransfer` and `XHCIEPContext` the outer call stack is still holding. | \# | entry point | trigger | host actor needed? | |----|-------------|---------|--------------------| | A | `xhci_complete()` `hcd-xhci.c:3284` | the guest's own bulk SCSI read completing, via `-device usb-storage` | **none** | | B | `xhci_wakeup_endpoint()` `hcd-xhci.c:3343` | an ordinary console pointer event, via `-device usb-tablet` | operator moves the mouse | Variant A is the one that matters: the entire ASan stack below `xhci_complete()` is block-layer AIO (`coroutine_trampoline` -\> `blk_aio_complete` -\> `scsi_read_complete_noio` -\> `usb_msd_transfer_data`). No UI, no monitor, no human. QEMU's own documentation recommends `qemu-xhci` as the USB controller to use (`docs/system/devices/usb.rst:14-21`) and documents `usb-storage` attached to an xHCI bus as the example mass-storage configuration (`docs/system/devices/usb.rst:113-125`). Reported By: Ken Hsu, Royce Lu, and Bo Qu of Palo Alto Networks # Environment Reproduced on current master: - QEMU commit: `81ce3a87737aa50716c42db8886082d12783e0a1` (2026-09-27) - QEMU version string: `QEMU emulator version 11.1.50 (v11.1.0-1870-g81ce3a8773)` - target: `x86_64-softmmu` - machine: `q35`, `-accel qtest`, `-m 128M`, `-nodefaults` - devices: `-device qemu-xhci` or `-device nec-usb-xhci`, plus `-device usb-storage` (variant A) or `-device usb-tablet` (variant B). No custom device property is set on either controller; MSI-X is on by default. - trigger interface: guest MMIO to BAR0 and guest PCI config writes only. Variant A needs nothing else. Variant B additionally needs one pointer event, which the PoC delivers through QMP `input-send-event` because a qtest guest has no console — see the note in Impact. - ASan build: `CC=clang CXX=clang++ ../configure --enable-asan --enable-ubsan --disable-werror --target-list=x86_64-softmmu` - ASan options: `detect_leaks=0` The tested tree already contains the CVE-2026-17588 fix.\*\* `git merge-base --is-ancestor` confirms both `f91b0544fe` and `89e653b773` are ancestors of `81ce3a8773`, as is the reentrancy-guard infrastructure itself (`a2e1753b80`, first release v8.1.0). The PoCs still triggers UAF. # Root Cause Analysis The chain has three links/dependencies, and only the third is a bug. Separating them matters, because the fix touches only the third and the second one is the reason why the existing CVE-2026-17588 fix cannot be extended to cover this bug variant. ## **Precondition 1 (by design) - the MSI-X table and the doorbell array are the same `MemoryRegion`.** ```c /* hw/usb/hcd-xhci-pci.c:35-36 */ #define OFF_MSIX_TABLE 0x3000 #define OFF_MSIX_PBA 0x3800 ``` ```c /* hw/usb/hcd-xhci-pci.c:175-179 */ if (s->msix != ON_OFF_AUTO_OFF) { ret = msix_init(dev, s->xhci.numintrs, &s->xhci.mem, 0, OFF_MSIX_TABLE, &s->xhci.mem, 0, OFF_MSIX_PBA, 0x90, s->msix == ON_OFF_AUTO_ON ? errp : NULL); ``` `&s->xhci.mem` is BAR0, and the doorbell subregion sits at offset `0x2000` of it - `#define OFF_DOORBELL 0x2000` (`hw/usb/hcd-xhci.c:54`), added to the same region by `memory_region_add_subregion(&xhci->mem, OFF_DOORBELL, &xhci->mem_doorbell)` (`hw/usb/hcd-xhci.c:3452`). So an MSI-X message address of `BAR0 + 0x2000` - a value the guest writes into the MSI-X table itself. This makes every interrupt delivery a write to doorbell register 0. With BAR0 at `0xfeb00000`, that address is `0xfeb02000`. This is intended implementation by design. PCI permits the MSI-X table to live in any BAR at any offset, and putting it in the register BAR is normal. It is listed only because it is what gives the guest a re-entry target. ## **Precondition 2 (a property of the memory API) - the MSI-X delivery path is not subject to `MemTxAttrs.memory`.** ```c /* hw/pci/pci.c:449-467 */ static void pci_msi_trigger(PCIDevice *dev, MSIMessage msg) { MemTxAttrs attrs = {}; ... attrs.requester_id = pci_requester_id(dev); address_space_stl_le(&dev->bus_master_as, msg.address, msg.data, attrs, NULL); } ``` `attrs` is zero-initialised, so `.memory` is false, and in any case `address_space_stl_le()` reaches `memory_region_dispatch_write()` through `address_space_stm_internal()` (`system/memory_ldst.c.inc:70-99`) without ever consulting `flatview_access_allowed()`. That helper is only called from the `flatview_read`/`flatview_write` in `system/physmem.c`. This is why `89e653b773` is structurally unable to cover this sink, however many more DMA sites it is extended to. ## **The bug - the completion and wakeup callbacks run without the guard.** ```c /* hw/usb/hcd-xhci.c:3284-3297 */ static void xhci_complete(USBPort *port, USBPacket *packet) { XHCITransfer *xfer = container_of(packet, XHCITransfer, packet); if (packet->status == USB_RET_REMOVE_FROM_QUEUE) { xhci_ep_nuke_one_xfer(xfer, 0); return; } xhci_try_complete_packet(xfer); xhci_kick_epctx(xfer->epctx, xfer->streamid); if (xfer->complete) { xhci_ep_free_xfer(xfer); } } ``` There is no `mem_reentrancy_guard` here, and none in `xhci_wakeup_endpoint()` (`:3343-3357`), `xhci_attach()` (`:3254`), `xhci_detach()` (`:3262`), `xhci_wakeup()` (`:3271`) or `xhci_child_detach()` (`:3299`). The guard is set automatically only by the MMIO dispatch layer (`system/memory.c:546-556`). Every other entry point has to set it itself, which is exactly what `f91b0544fe` did for the two timers and what EHCI/UHCI/DWC2 get from `qemu_bh_new_guarded()` (`hw/usb/hcd-ehci.c:2646`, `hw/usb/hcd-uhci.c:1221`, `hw/usb/hcd-dwc2.c:1372`). ## The Re-Entrant Chain The event-raising path is gated 3 times in `xhci_intr_raise()` (`:581-604`) - by the `ERDP.EHB` latch, by `IMAN.IE`, and by `USBCMD.INTE`. `msix_notify()` additionally returns early unless `msix_entry_used[vector]` is set (`hw/pci/msix.c:546-548`). The guest satisfies all four from its own MMIO and config writes before firing; the PoC section below lists the order, which is crucial to trigger the bug. The **free** stack (variant A, `qemu-xhci`), from `traces/asan_storage_uaf_qemu.txt`. Frame numbers, symbols and `file:line` are reproduced unchanged. ``` freed by thread T0 here: #1 xhci_ep_nuke_xfers ../hw/usb/hcd-xhci.c:1277:9 #2 xhci_disable_ep ../hw/usb/hcd-xhci.c:1304:5 #3 xhci_disable_slot ../hw/usb/hcd-xhci.c:2061:13 #4 xhci_process_commands ../hw/usb/hcd-xhci.c:2516:31 #5 memory_region_write_accessor ../system/memory.c:492:5 #6 access_with_adjusted_size ../system/memory.c:568:18 #7 memory_region_dispatch_write ../system/memory.c #8 address_space_stm_internal ../system/memory_ldst.c.inc:85:13 #9 xhci_pci_intr_raise ../hw/usb/hcd-xhci-pci.c:72:9 <- msix_notify() #10 xhci_intr_raise ../hw/usb/hcd-xhci.c:600:13 #11 xhci_event ../hw/usb/hcd-xhci.c:686:5 #12 xhci_xfer_report ../hw/usb/hcd-xhci.c:1574:13 #13 xhci_complete ../hw/usb/hcd-xhci.c:3292:5 <- UNGUARDED #14 usb_packet_complete ../hw/usb/core.c:502:5 #15 usb_msd_command_complete ../hw/usb/dev-storage.c:299:9 #16 scsi_req_complete ../hw/scsi/scsi-bus.c:1651:5 #17 usb_msd_transfer_data ../hw/usb/dev-storage.c:255:9 #18 scsi_read_complete_noio ../hw/scsi/scsi-disk.c:448:5 #19 blk_aio_complete ../block/block-backend.c:1586:9 #20 coroutine_trampoline ../util/coroutine-ucontext.c:175:9 ``` Note the frames #14 through #20. The outermost frame is a block-layer AIO completion. Nothing outside the guest appears anywhere in the stack. And the **access** stack, after the inner command unwinds and control returns to `xhci_xfer_report()`: ``` ERROR: AddressSanitizer: heap-use-after-free on address 0x5110000932d8 READ of size 4 at 0x5110000932d8 thread T0 #0 xhci_xfer_report ../hw/usb/hcd-xhci.c:1576:23 #1 xhci_complete ../hw/usb/hcd-xhci.c:3292:5 ... 0x5110000932d8 is located 216 bytes inside of 256-byte region [0x511000093200,0x511000093300) ``` `:1576` is `if (xfer->status != CC_SUCCESS)`, reading the `XHCITransfer` that frame #13's own callee just freed. ## Possible Write Primitives ASan aborts on the first use (a **read**), so the trace stops there. On a regular build, execution continues through `xhci_complete()` and touches freed memory a few more times (including 2 **writes**, a double free). Two distinct objects are already freed when `xhci_complete()` is entered: - **`xfer`** (`XHCITransfer`) - freed by `xhci_ep_free_xfer()` inlined into `xhci_ep_nuke_xfers()` at `:1277`. This is the object ASan reports, and `:1277` is what frame #1 of its free stack names. - **`epctx`** (`XHCIEPContext`) - freed by `xhci_disable_ep()` at `:1318` (`g_free(epctx)`), reached from the same doorbell re-entry. The following annotated code snippet below is from `hw/usb/hcd-xhci.c` at `81ce3a8773`. ```c 3284 static void xhci_complete(USBPort *port, USBPacket *packet) 3285 { 3286 XHCITransfer *xfer = container_of(packet, XHCITransfer, packet); 3287 3288 if (packet->status == USB_RET_REMOVE_FROM_QUEUE) { 3289 xhci_ep_nuke_one_xfer(xfer, 0); 3290 return; 3291 } 3292 xhci_try_complete_packet(xfer); // <== ASan aborts inside this call // (:1576, "xfer->status"): // the first UAF read 3293 xhci_kick_epctx(xfer->epctx, xfer->streamid); // <== (1) two UAF reads of freed xfer, // and the whole call then runs on // the freed epctx 3294 if (xfer->complete) { // <== (2) UAF read of freed xfer 3295 xhci_ep_free_xfer(xfer); // descends into the block below 3296 } 3297 } ``` ```c 1200 static void xhci_ep_free_xfer(XHCITransfer *xfer) 1201 { 1202 QTAILQ_REMOVE(&xfer->epctx->transfers, xfer, next); // <== (3) UAF WRITE: updates the freed // epctx's list head, and writes the // freed xfer's own link field 1203 xfer->epctx->xfer_count--; // <== (4) UAF WRITE to freed epctx 1204 1205 usb_packet_cleanup(&xfer->packet); 1206 g_free(xfer->trbs); 1207 g_free(xfer); // <== (5) DOUBLE FREE: this exact // pointer was already freed at :1277 1208 } ``` ## Steps to reproduce 1. Do QEMU ASan build: ``` cd ~/targets/qemu && mkdir -p build-asan && cd build-asan && CC=clang CXX=clang++ ../configure --enable-asan --enable-ubsan --disable-werror --target-list=x86_64-softmmu ninja qemu-system-x86_64 ``` 2. Run the attached PoCs. They drive the controller over qtest and need no root, no guest image and no network: ``` cd poc python3 xhci_msix_storage_uaf.py <build-asan>/qemu-system-x86_64 qemu --drive null python3 xhci_msix_storage_uaf.py <build-asan>/qemu-system-x86_64 nec --drive null python3 xhci_msix_doorbell_uaf.py <build-asan>/qemu-system-x86_64 qemu python3 xhci_msix_doorbell_uaf.py <build-asan>/qemu-system-x86_64 nec ``` 3. Observe crashes for all four cases. The ASAN log will be like this ``` ================================================================= ==378317==ERROR: AddressSanitizer: heap-use-after-free on address 0x5110000937d8 at pc 0x5591f173c440 bp 0x7f09e58f5af0 sp 0x7f09e58f5ae8 READ of size 4 at 0x5110000937d8 thread T0 #0 0x5591f173c43f in xhci_xfer_report ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:1576:23 #1 0x5591f1743c1b in xhci_complete ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:3292:5 #2 0x5591f16bd0bc in usb_packet_complete ~/targets/qemu/build-asan/../hw/usb/core.c:502:5 #3 0x5591f17668e9 in usb_msd_command_complete ~/targets/qemu/build-asan/../hw/usb/dev-storage.c:299:9 #4 0x5591f15147d1 in scsi_req_complete ~/targets/qemu/build-asan/../hw/scsi/scsi-bus.c:1651:5 #5 0x5591f17651bd in usb_msd_transfer_data ~/targets/qemu/build-asan/../hw/usb/dev-storage.c:255:9 #6 0x5591f152bb03 in scsi_read_complete_noio ~/targets/qemu/build-asan/../hw/scsi/scsi-disk.c:448:5 #7 0x5591f22b2a0e in blk_aio_complete ~/targets/qemu/build-asan/../block/block-backend.c:1586:9 #8 0x5591f28235a9 in coroutine_trampoline ~/targets/qemu/build-asan/../util/coroutine-ucontext.c:175:9 #9 0x7f09eba2e80f (/lib/x86_64-linux-gnu/libc.so.6+0x5880f) 0x5110000937d8 is located 216 bytes inside of 256-byte region [0x511000093700,0x511000093800) freed by thread T0 here: #0 0x5591f08b890a in free (qemu-system-x86_64+0x1a3e90a) #1 0x5591f1745be7 in xhci_ep_nuke_xfers ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:1277:9 #2 0x5591f1751e22 in xhci_disable_ep ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:1304:5 #3 0x5591f17517f7 in xhci_disable_slot ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:2061:13 #4 0x5591f174cd9d in xhci_process_commands ~/targets/qemu/build-asan/../hw/usb/hcd-xhci.c:2516:31 ... ... ``` # Impact, Exploitability, And Severity Severity: High Impact: reliable DoS resulted from use-after-free (**observed**). Exploitability: RCE plausible (?) There are two use-after-free writes through a freed `XHCIEPContext`, a full `xhci_kick_epctx()` running on that freed context, and a double free of a 256-byte heap object. Typically I'd think these are interesting enough to give exploitation a shot, but that doesn't imply successful exploitation is guaranteed. # Suggested Fix Attached as `patches/xhci-guard-completion-paths.diff`, against `81ce3a8773`. 0 errors and 0 warnings from `scripts/checkpatch.pl`, but it's better to take another look and be sure. Engage `mem_reentrancy_guard` across the `USBPortOps` and `USBBusOps` callbacks, the same way `f91b0544fe` did for the timer callbacks. One difference matters: the timer fix can `assert(!guard->engaged_in_io)` because a timer never runs nested inside an MMIO handler, but these callbacks _can_ be reached from inside one - a packet that completes synchronously inside a doorbell write goes through `xhci_complete()` on that same stack. So the previous value has to be saved and restored: ```c static bool xhci_engage_guard(XHCIState *xhci) { MemReentrancyGuard *guard = &xhci->parent.mem_reentrancy_guard; bool engaged = guard->engaged_in_io; guard->engaged_in_io = true; return engaged; } static void xhci_restore_guard(XHCIState *xhci, bool engaged) { xhci->parent.mem_reentrancy_guard.engaged_in_io = engaged; } ``` applied to `xhci_complete()`, `xhci_wakeup_endpoint()`, `xhci_attach()`, `xhci_detach()`, `xhci_wakeup()` and `xhci_child_detach()`. Only the first two are demonstrated here; the other four reach the same `xhci_event()` -\> `xhci_intr_raise()` sink from outside MMIO context and are covered for the same reason. # Additional Info This issue was found on 2026-09-29 against git master (`81ce3a8773`). ## Why this was not found alongside CVE-2026-17588 I was a bit surprised that this one slipped. So I used AI to help me check by building a pre-fix build and ran both PoCs (CVE-2026-17588 poc + poc from this report). It appears that the bug was present the whole time, and the crash report was pretty much **indistinguishable.** Test tree: `7074591d79`, i.e. `f91b0544fe^`. Clean worktree, same ASan configure line as above, `QEMU emulator version 11.1.50 (v11.1.0-1709-g7074591d79)`. **1. The bug predates the fix.** Variant A reproduces unchanged on that tree (`traces/prefix_asan_storage_uaf_qemu.txt`): ``` ERROR: AddressSanitizer: heap-use-after-free on address 0x5110000932d8 READ of size 4 at 0x5110000932d8 thread T0 #0 xhci_xfer_report ../hw/usb/hcd-xhci.c:1562:23 #1 xhci_complete ../hw/usb/hcd-xhci.c:3290:5 ... #7 blk_aio_complete ../block/block-backend.c:1586:9 #8 coroutine_trampoline ../util/coroutine-ucontext.c:175:9 ``` The line numbers read `:1562` and `:3290` rather than `:1576` and `:3292` purely from line shifts - four commits have touched `hcd-xhci.c` since. The code is the same: pre-fix `:1562` and HEAD `:1576` are both the statement `if (xfer->status != CC_SUCCESS) {`, and `xhci_complete()` is byte-identical on the two trees. So the fix did not create this path - it removed the easier-to-spot bug that was standing in front of it. Re-entrancy is pretty hard, and we all overlook :/ **2. Pre-fix, the two bugs are indistinguishable at the top of the ASan report.** Running the original CVE-2026-17588 poc (i.e `work_items/4195` PoC) against that same binary (`traces/prefix_asan_cve_2026_17588_poc.txt`) gives: ``` ERROR: AddressSanitizer: heap-use-after-free on address 0x51100008f318 READ of size 4 at 0x51100008f318 thread T0 #0 xhci_xfer_report ../hw/usb/hcd-xhci.c:1562:23 #1 xhci_kick_epctx ../hw/usb/hcd-xhci.c #2 timerlist_run_timers ../util/qemu-timer.c:593:9 ``` Side by Side Comparison | | CVE-2026-17588 PoC | this report | |--|--------------------|-------------| | ASan error class | heap-use-after-free, READ of size 4 | **identical** | | crash site | `xhci_xfer_report ../hw/usb/hcd-xhci.c:1562:23` | **identical** | | freed object | 216 bytes into a 256-byte region | **identical** | | free stack, frames #0–#7 | `free` → `xhci_ep_nuke_xfers:1263` → `xhci_disable_ep:1290` → `xhci_disable_slot:2060` → `xhci_process_commands:2514` → `memory_region_write_accessor` → `access_with_adjusted_size` → `memory_region_dispatch_write` | **identical** | | access stack, frame #1 — _who called_ `xhci_xfer_report()` | `xhci_kick_epctx` | `xhci_complete` | | what drives that call | a virtual-clock timer (`timerlist_run_timers`) | a block-layer AIO completion (`coroutine_trampoline` → `blk_aio_complete`) | | free stack, frames #8+ — _which store_ re-entered | `flatview_write` → `dma_memory_write` → `xhci_write_event:625` | `address_space_stm_internal:85` → `xhci_pci_intr_raise:72` (`msix_notify()`) |