QEMU xHCI CVE-2026-17588

Requires an attacker with code execution inside a guest VM that is configured with an emulated xHCI (USB 3.0) host controller in QEMU, and the ability to drive that controller's registers/timers (typically guest kernel or driver-level access to the USB device). This is a guest-to-host (scope-changing) issue: exploitation is not possible from the network or from an unprivileged remote actor, and it does not apply to VMs without an emulated xHCI controller or those using USB passthrough only. Limiting factors: the reentrancy condition is a race-like nested-callback state that is hard to trigger deterministically, and the practical outcome is most often a QEMU crash (DoS) rather than reliable code execution.

This CVE lacks a published CVSS score, CVSS vector, EPSS probability, KEV listing, and POC indicator in the provided data, so quantitative risk signals are absent and the assessment below is inferred from the patch title and QEMU's well-known device-emulation threat model. The change - 'hw/usb/hcd-xhci: Set reentrancy guard in timer functions' - is a defense against DMA/MMIO-driven reentrancy in the emulated xHCI USB host controller, a class of QEMU bug where a device callback re-enters device code and corrupts state (typically use-after-free), which is triggerable only by a party that already controls the guest and can drive the emulated xHCI controller. Realistically this is a guest-to-host issue whose most likely outcome is a QEMU process crash (host/guest DoS), with a residual possibility of memory corruption that a skilled attacker could escalate toward host code execution or VM escape. Absent KEV or EPSS data there is no evidence of active or widespread exploitation; reentrancy races are generally difficult to weaponize reliably, so this should be treated as a patch-on-normal-cycle hardening fix rather than an emergency, while noting that QEMU's ubiquity in cloud virtualization raises the aggregate stakes. Key uncertainty: no vendor CVSS was provided - the scope-change and impact metrics below are my independent estimate and should be verified against the upstream QEMU advisory and the Ubuntu security notice.

A malicious or compromised guest that can issue MMIO/register operations to the emulated xHCI USB controller schedules or triggers controller activity such that a QEMU timer callback re-enters the xHCI device code before the prior operation completes, corrupting internal state (use-after-free). The most reliable result is a crash of the QEMU process, denying service to that VM and its host workload; memory corruption could in principle be steered toward host-side code execution. No public exploit was identified at time of analysis.