Re: [PATCH 0/3] Harden virtio migration load paths against crafted streams

[Kevin Wolf <kwolf@redhat.com>]

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