QEMU virtio-blk: malformed guest SCSI request causes host-heap out-of-bounds write

Impact

QEMU's virtio-blk device fails to validate input descriptor sizes before writing, so a guest can submit a malformed virtio-blk SCSI request and force an out-of-bounds write in the QEMU process's host heap. Red Hat scores the confirmed outcome as denial of service of the QEMU process with a scope change, meaning a single tenant VM can kill its own hypervisor process and, given a heap write primitive, the blast radius on a shared host is worth assuming to be larger than DoS until proven otherwise. On a GPU cloud that rents out passthrough or vGPU-backed VMs, this is a tenant-reachable bug against the host-side emulator on a node that is expensive to evacuate. The record notes it requires high privileges inside the guest - i.e. root in the tenant VM, which a tenant normally has.

Who can reach it

A malicious guest with root/high privileges inside a VM backed by QEMU virtio-blk. No host credentials needed; reachable from any tenant VM using virtio-blk storage.

What to do

Apply the QEMU/qemu-kvm update from your distribution - Red Hat ships RHSA-2026:39311, and the upstream fix is on qemu-devel (posting 20260526154957.1741622-1-stefanha@redhat.com). Running VMs keep the old QEMU binary until they are restarted, so each guest must be live-migrated or shut down and restarted after the package update; plan a rolling migration rather than expecting the package upgrade alone to close it.

References