On Fri, Jul 10, 2026 at 12:28:56PM +0200, Laurent Vivier wrote: > A crafted migration stream can crash the destination QEMU process > through unvalidated fields in the virtio device state: an unbounded > allocation in virtio-serial, reachable assertions in the shared > virtqueue element deserializer, and assert()/exit(1) calls in > virtio-scsi request loading. > > These are hardening fixes: the destination QEMU is in a paused > pre-start state and the source VM is unaffected by a failed migration. > > Patch 1 validates the virtio-serial nr_active_ports count against the > configured maximum before allocating the post-load array. > > Patch 2 replaces the assertions in qemu_get_virtqueue_element() with > a bounds check returning NULL, and updates all callers (virtio-serial, > virtio-blk, virtio-scsi, scsi-bus) to handle the failure gracefully. > > Patch 3 replaces the remaining assert() and exit(1) calls in > virtio_scsi_load_request() with proper error returns. > > Tested with migration round-trips for virtio-serial (0 to 511 ports), > virtio-blk (1-2 disks), and virtio-scsi (1-2 disks), plus the > original PoC reproducers for issues #3801 and #3802. > > Laurent Vivier (3): > hw/char/virtio-serial-bus: validate nr_active_ports from migration > stream > hw/virtio: return NULL from qemu_get_virtqueue_element() on invalid > state > hw/scsi/virtio-scsi: harden virtio_scsi_load_request() against invalid > stream
Kevin objected to my version of this, I guess same will apply? > hw/block/virtio-blk.c | 4 ++++ > hw/char/virtio-serial-bus.c | 7 +++++++ > hw/scsi/scsi-bus.c | 4 ++++ > hw/scsi/virtio-scsi.c | 20 ++++++++++++++++---- > hw/virtio/virtio.c | 11 ++++------- > 5 files changed, 35 insertions(+), 11 deletions(-) A similar exit in mptsas? > -- > 2.54.0
