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

On Wed, Jul 29, 2026 at 10:56:56AM +0200, Laurent Vivier wrote:
> On 7/28/26 17:00, Kevin Wolf wrote:
> > 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.
> 
> Michael,
> 
> will you rework your series or do you prefer I update mine?
> 
> Thanks,
> Laurent

Pls go ahead, thanks a lot!