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.
pgpda3jIN2jNn.pgp
Description: PGP signature
