On Sun, 19 Jul 2026 at 07:15, Thomas Huth <[email protected]> wrote: > > From: Thomas Huth <[email protected]> > > Some machines like the microvm machine instantiate a "sysbus-xhci" > device with just 1 interrupt (by setting the "intrs" property to 1). > xhci_sysbus_realize() then only allocates the s->irq array with one > entry. > > When the guest writes to the ERDP register of a corresponding XHCI > "interrupter", the generic XHCI code calls the xhci_sysbus_intr_raise() > function with n > 1, and this function then calls qemu_set_irq() with > s->irq[n] pointing to a bad heap address. The qemu_set_irq() then tries > to call an IRQ handler via a function pointer in that heap space. This > either causes QEMU to die with a segmentation fault (if it's a bad > address), or even worse runs some unexpected code if the destination > of the pointer is executable code. > > Looking at the xHCI spec, it is up to the implementation of the host > controller how many interrupters are available. So if we only support > one or some few interrupters, the registers of the other interrupters > should not do anything, i.e. reads should result in zeros and writes > should be completely ignored. (big thanks to Peter Maydell for helping > with the analyzation of the correct way to fix this here) > > This way, the xhci_sysbus_intr_raise() function cannot be called with > an invalid interrupt number anymore. But for good measure, also add an > assert() statement to the xhci_sysbus_intr_raise() function to prevent > that similar problems with calling arbitrary function pointers on the > heap could occur again. > > Fixes: CVE-2026-16043 > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4001 > Reported-by: Tristan Madani <[email protected]> > Signed-off-by: Thomas Huth <[email protected]> > --- > v3: Use correct word "nonexistent" and don't skip trace in read function
Reviewed-by: Peter Maydell <[email protected]> thanks -- PMM
