Re: [Qemu-devel] [PATCH for-2.0 16/47] vdi: add bounds checks for blocks_in_image and disk_size header fields (CVE-2014-0144)

[Stefan Hajnoczi]

On Thu, Mar 27, 2014 at 08:58:38PM +0100, Stefan Weil wrote:
> Am 27.03.2014 19:52, schrieb Jeff Cody:
> >> Do we need this patch for QEMU 2.0? For 32 bit systems, the image size
> >> limit is 1000 TB, and that image would need 4 GB for the block cache in
> >> memory. Are such image sizes used anywhere? For 64 bit systems, the
> >> limit will be much higher.
> >>
> > 
> > I don't know what systems are in use in the wild.  But since we
> > allocate block cache to fit the entire cache in RAM currently, that
> > does open us up to potentially allocating a lot of memory, based on
> > what the image file header specifies.
> > 
> > That is a reason to keep the maximum blocks_in_image size bounded to
> > the size of 0x3fffffff.  With an unbound blocks_in_image size (except
> > to UINT32_MAX), the driver would potentially attempt to allocate 16GB
> > of RAM, if qemu attempts to open a VDI image file with such a header.
> 
> Either we crash because of the 0x3fffffff limit, or we might crash
> because a memory allocation fails (but it might also be successful). I
> prefer this 2nd variant.

>From a user perspective, hotplugging a disk should never kill the VM.
Instead the hotplug command should fail for invalid image files.

If a valid image can cause QEMU abort then the block driver
implementation needs to use a metadata cache to avoid putting everything
in RAM.

Stefan