Re: [Qemu-devel] [PATCH v4 00/21] block: Handle failure for potentially large allocations

[Stefan Hajnoczi]

On Thu, Jun 05, 2014 at 03:36:12PM +0200, Kevin Wolf wrote:
> A not too small part of the recent CVEs were DoS scenarios by letting
> qemu abort with too large memory allocations. We generally "fixed" these
> cases by setting some limits on values read from image files that
> influence the size of allocations.
> 
> Because we still need to allow reading large images, this works only to
> a certain degree and we still can get fairly large allocations, which
> are not unthinkable to fail on some machines.
> 
> This series converts potentially large allocations to g_try_malloc() and
> friends and handles failure gracefully e.g. by returning -ENOMEM. This
> may cause hot-plug of a new disk or individual requests to fail, but the
> VM as a whole can keep running.
> 
> v4:
> - Patch 11 (qcow2): Fix memory leak in qcow2_cache_create() [Benoît]
> 
> v3:
> - Changed qemu_try_blockalign() to only return NULL on failure. size = 0
>   results in a small allocation now (size of the alignment) [Benoît]
> - Patch 8 (nfs): Check for size != 0 before failing [Benoît]
> - Patch 11 (qcow2):
>   * Fix memory leak in alloc_refcount_block() [Max]
>   * Report internal error for -ENOMEM in qcow2_check() [Max]
> - Patch 15 (rbd): Build fix [Markus]
> 
> v2:
> - Some more places check for size = 0 before they treat NULL as an error
> - Patch 2 (block.c): Added missing NULL return check for
>   qemu_try_blockalign() [Stefan]
> - Patch 7 (iscsi): Fixed acb->task memory leak [Stefan]
> - For conversions from g_malloc() to qemu_try_blockalign(), made sure to
>   be consistent about pairing the latter with qemu_vfree() [Stefan]

Turns out the qemu_try_blockalign() assertion is being triggered by
qemu-iotests.  Please rerun ./check && ./check -qcow2.

I've dropped it from the block queue.

pgpQSZtt8krMX.pgp
Description: PGP signature