Am 25.07.2026 um 17:34 hat Michael S. Tsirkin geschrieben: > 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?
Objecting is a big word. I suggested some improvements around passing errors to the caller instead of trying to handle everything locally. But yes, at the first sight I think they would apply here, too. Kevin
