QEMU VMDK driver: a crafted image causes an out-of-bounds read leaking 12 bytes or crashing the process

Impact

A specially crafted VMDK image makes the QEMU block layer read past the end of a buffer, leaking up to 12 bytes of process memory or killing the process. The record describes nothing beyond that: no write primitive and no escape. The realistic exposure for an operator is untrusted image handling rather than a running guest, since a VM-based GPU cloud that lets customers upload their own disk images will parse those images with qemu-img or a QEMU process on a management host. Twelve bytes is small, but it comes from the address space of a process that also handles other tenants' images.

Who can reach it

Anyone who can get a VMDK image parsed by QEMU or qemu-img, typically a tenant uploading or converting a disk image. Local vector per the CVSS; no authentication to the host is required, only the ability to supply the file.

What to do

Update the QEMU packages for your distribution (Red Hat tracks it for RHEL 6 through 10 and OpenShift Container Platform 4; no fixed version is named in the record). Image conversion and inspection tooling picks up the fix on the next invocation, so the operational cost there is just the package update. Running guests keep the old binary until they are migrated off and restarted, which on a GPU host means draining tenant VMs. Reject or convert customer-supplied VMDK images in a sandboxed, unprivileged conversion worker rather than on a host that also serves other tenants.

References