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
