From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wufr0-0002dk-Rz for qemu-devel@nongnu.org; Wed, 11 Jun 2014 06:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wufqv-0000Ex-T9 for qemu-devel@nongnu.org; Wed, 11 Jun 2014 06:34:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wufqv-0000Dn-L8 for qemu-devel@nongnu.org; Wed, 11 Jun 2014 06:33:57 -0400 Date: Wed, 11 Jun 2014 12:33:53 +0200 From: Stefan Hajnoczi Message-ID: <20140611103353.GE6673@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="a+b56+3nqLzpiR9O" 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 --a+b56+3nqLzpiR9O 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] >=20 > *** BLURB HERE *** >=20 > Kevin Wolf (20): > block: Introduce qemu_try_blockalign() > block: Handle failure for potentially large allocations > bochs: Handle failure for potentially large allocations > cloop: Handle failure for potentially large allocations > curl: Handle failure for potentially large allocations > dmg: Handle failure for potentially large allocations > iscsi: Handle failure for potentially large allocations > nfs: Handle failure for potentially large allocations > parallels: Handle failure for potentially large allocations > qcow1: Handle failure for potentially large allocations > qcow2: Handle failure for potentially large allocations > qed: Handle failure for potentially large allocations > raw-posix: Handle failure for potentially large allocations > raw-win32: Handle failure for potentially large allocations > rbd: Handle failure for potentially large allocations > vdi: Handle failure for potentially large allocations > vhdx: Handle failure for potentially large allocations > vmdk: Handle failure for potentially large allocations > vpc: Handle failure for potentially large allocations > mirror: Handle failure for potentially large allocations >=20 > Max Reitz (1): > qcow2: Return useful error code in refcount_init() >=20 > block.c | 47 ++++++++++++++++++++++++++++++++++++------- > block/bochs.c | 6 +++++- > block/cloop.c | 23 ++++++++++++++++++--- > block/curl.c | 8 +++++++- > block/dmg.c | 19 ++++++++++++------ > block/iscsi.c | 17 +++++++++++++--- > block/mirror.c | 7 ++++++- > block/nfs.c | 6 +++++- > block/parallels.c | 6 +++++- > block/qcow.c | 33 +++++++++++++++++++++++------- > block/qcow2-cache.c | 13 +++++++++++- > block/qcow2-cluster.c | 35 ++++++++++++++++++++++++-------- > block/qcow2-refcount.c | 54 +++++++++++++++++++++++++++++++++++++++-----= ------ > block/qcow2-snapshot.c | 22 +++++++++++++++----- > block/qcow2.c | 41 ++++++++++++++++++++++++++++++-------- > block/qed-check.c | 7 +++++-- > block/qed.c | 6 +++++- > block/raw-posix.c | 6 +++++- > block/rbd.c | 7 +++++-- > block/vdi.c | 24 +++++++++++++++++----- > block/vhdx-log.c | 6 +++++- > block/vhdx.c | 12 +++++++++-- > block/vmdk.c | 12 +++++++++-- > block/vpc.c | 6 +++++- > block/win32-aio.c | 6 +++++- > include/block/block.h | 1 + > include/qemu/osdep.h | 1 + > util/oslib-posix.c | 16 +++++++++------ > util/oslib-win32.c | 9 +++++++-- > 29 files changed, 365 insertions(+), 91 deletions(-) >=20 > --=20 > 1.8.3.1 >=20 Thanks, applied to my block tree: https://github.com/stefanha/qemu/commits/block Stefan --a+b56+3nqLzpiR9O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTmDCRAAoJEJykq7OBq3PIvwUH/1/BL6bbKH0Iip3IskQaqmKL Ks7Ir5rgbHm2jHg6J1a8mRHy8jMoBxzBDccx5Nqvj57bDJwMR0LZVJOgIH2/CahL dObo0BU7jDF3Ud4/ATNiBuk8GVe/+nIYCrLvf/8Rd/oznPCBL9pXaXCKBw3isQby fb286bxVOZHRri5P8Yy8a5ifnilF8+C+VMIJ/Th4g0ZF1HdQ4FSv6/Tu4c5qNpVo DE+BgZDzr06A4QItUW66IPPXpgH4mUav47nSJ45q+4SvTK9SzCMFjZX/KmuRl3qg JnVoRxYeZbkaKKVgMRC31TcRbORMn0T61oiSh+VxhpaS8Cr+YrliAU3PSLb3Kr4= =m1aV -----END PGP SIGNATURE----- --a+b56+3nqLzpiR9O--