From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wujdl-0005LD-EL for qemu-devel@nongnu.org; Wed, 11 Jun 2014 10:36:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wujdc-0002C4-CV for qemu-devel@nongnu.org; Wed, 11 Jun 2014 10:36:37 -0400 Received: from mail-wg0-x234.google.com ([2a00:1450:400c:c00::234]:61376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wujdc-0002BM-6H for qemu-devel@nongnu.org; Wed, 11 Jun 2014 10:36:28 -0400 Received: by mail-wg0-f52.google.com with SMTP id b13so4393415wgh.35 for ; Wed, 11 Jun 2014 07:36:25 -0700 (PDT) Date: Wed, 11 Jun 2014 16:36:17 +0200 From: Stefan Hajnoczi Message-ID: <20140611143617.GA22146@stefanha-thinkpad.str.redhat.com> References: <1401975393-7255-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <1401975393-7255-1-git-send-email-kwolf@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 00/21] block: Handle failure for potentially large allocations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: benoit.canet@irqsave.net, qemu-devel@nongnu.org, stefanha@redhat.com --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. >=20 > v4: > - Patch 11 (qcow2): Fix memory leak in qcow2_cache_create() [Beno=EEt] >=20 > v3: > - Changed qemu_try_blockalign() to only return NULL on failure. size =3D 0 > results in a small allocation now (size of the alignment) [Beno=EEt] > - Patch 8 (nfs): Check for size !=3D 0 before failing [Beno=EEt] > - 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] >=20 > v2: > - Some more places check for size =3D 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. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTmGlhAAoJEJykq7OBq3PIQRkH/RW+n5edPGV6QC7O/Bl+M2sB TV02yc1wXEHNupGjpIJN8FkFdZ+nhw0fQEigTncg/DeUuGQmRtXkDe90VRPpQ5pH xtUfVcb3BXzTVe/Ichpcb2SQyfMd+rK/3D7PIdocGx5fxN0mwCqGL5V64U4MX+Y2 VR8rG5lEVhn/vihlHuuyo8ik8kBqI5ian/SpvpMS4JeavgwLalboo11927z8Qb+d 41Uw0wAPJ6Y2Q7E2J3aD6uzxHawIkYT1gFuFjGQxCEE2zIINnsVy79328958GNRl BQvTXmpTPb3oQlA3iA2FJbvvBGOq1wYlXEfRbs/D23/uqmPmebJq01jnZ8GJAp0= =psYa -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--