Information leak via crafted user-supplied CDROM

ISSUE DESCRIPTION

QEMU handles many different file formats for virtual disks (e.g., raw, qcow2, vhd, &c). Some of these formats are “snapshots” that specify “patches” to an alternate disk image, whose filename is included in the snapshot file.
When qemu is given a disk but the type is not specified, it attempts to guess the file format by reading it. If a disk image is intended to be ‘raw’, but the image is entirely controlled by an attacker, the attacker could write a header to the image, describing one of these “snapshot” formats, and pointing to an arbitrary file as the “backing” file.
When attaching disks via command-line parameters at boot time (including both “normal” disks and CDROMs), libxl specifies the format; however, when inserting a CDROM live via QMP, the format was not specified.

IMPACT

An attacker supplying a crafted CDROM image can read any file (or device node) on the dom0 filesystem with the permissions of the qemu devicemodel process. (The virtual CDROM device is read-only, so no data can be written.)

VULNERABLE SYSTEMS

Only x86 HVM guests with a virtual CDROM device are affected. ARM guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a virtual CDROM device are not affected.
Only systems with qemu running in dom0 are affected; systems running stub domains are not affected. Only systems using qemu-xen (aka “qemu-upstream” are affected; systems running qemu-xen-traditional are not affected.
Only systems in which an attacker can provide a raw CDROM image, and cause that image to be virtually inserted while the guest is running, are affected. Systems which only have host administrator-supplied CDROM images, or systems which allow images to be added only at boot time, are not affected.