From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5zzH-00029G-AB for qemu-devel@nongnu.org; Mon, 07 Dec 2015 12:54:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5zzG-0004Et-4V for qemu-devel@nongnu.org; Mon, 07 Dec 2015 12:54:11 -0500 References: <1449508029-14664-1-git-send-email-rkagan@virtuozzo.com> <5665C732.4010107@redhat.com> From: Eric Blake Message-ID: <5665C7BB.8040601@redhat.com> Date: Mon, 7 Dec 2015 10:54:03 -0700 MIME-Version: 1.0 In-Reply-To: <5665C732.4010107@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9mhhWTN505svsWvIGSdubOCnmmpnIitak" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH for-2.5?] qcow2: always initialize specific image info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Kagan , Kevin Wolf , qemu-block@nongnu.org Cc: Denis Lunev , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9mhhWTN505svsWvIGSdubOCnmmpnIitak Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/07/2015 10:51 AM, Eric Blake wrote: > [adding qemu-devel - ALL patches should go to qemu-devel, even if they > are also going to a sub-list like qemu-block] >=20 > On 12/07/2015 10:07 AM, Roman Kagan wrote: >> qcow2_get_specific_info() used to have a code path which would leave >> pointer to ImageInfoSpecificQCow2 uninitialized. >> >> We guess that it caused sporadic crashes on freeing an invalid pointer= >> in response to "query-block" QMP command in >> visit_type_ImageInfoSpecificQCow2 with QapiDeallocVisitor. >> >> Although we have neither a solid proof nor a reproduction scenario, >> making sure the field is initialized appears a reasonable thing to do.= >> >> Signed-off-by: Roman Kagan >> --- >> block/qcow2.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >=20 Oops; hit send too soon. I added for-2.5? to the subject line, because..= =2E >=20 >> >> diff --git a/block/qcow2.c b/block/qcow2.c >> index 88f56c8..67c9d3d 100644 >> --- a/block/qcow2.c >> +++ b/block/qcow2.c >> @@ -2739,7 +2739,7 @@ static ImageInfoSpecific *qcow2_get_specific_inf= o(BlockDriverState *bs) >> =20 >> *spec_info =3D (ImageInfoSpecific){ >> .type =3D IMAGE_INFO_SPECIFIC_KIND_QCOW2, >> - .u.qcow2 =3D g_new(ImageInfoSpecificQCow2, 1), >> + .u.qcow2 =3D g_new0(ImageInfoSpecificQCow2, 1), >=20 > NACK. This makes no difference, except when s->qcow_version is out of = spec. >=20 >> }; >> if (s->qcow_version =3D=3D 2) { >> *spec_info->u.qcow2 =3D (ImageInfoSpecificQCow2){ >> >=20 > If s->qcow_version is exactly 2, then we end up initializing all fields= > due to the assignment here; same if qcow_version is exactly 3. The onl= y > time qcow2 remains uninitialized is if qcow_version is 0, 1, or > 3; bu= t > we refuse to handle qcow files with out-of-range versions. So I don't > see how you are plugging any uninitialized values; and therefore, I > don't see how this is patching any crashes. =2E..if you can prove that we aren't gracefully handling an out-of-spec qcow_version, such that the uninitialized memory in that scenario is indeed causing a crash, then it is worth respinning a v2 of this patch with that proof, and worth considering it for 2.5 if it really is a crash fixer. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9mhhWTN505svsWvIGSdubOCnmmpnIitak Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWZce7AAoJEKeha0olJ0NqEAYH/3oxg4M1iby8zvcL2zNH/s3Y wd9k40EdMIpgHcSiD5TRgHxXINNia0gIwcnBv72/2SXSk00/SCea01KTOa2dhu8u TPcfD1Gp4/46XVoJ9tkYkyKltMq3JWMlRA9jY8xmo3VXJl8rCrcwPE8JQ7KfA0Ts gmZS5Q6wAqwga5QVBiss3uWKTmqCkGgeJUAXy/6lMCA2NETN3t1F0Nw44wODpsBo kw5YZ+FYYrLB9MkoGUOSD2yznSYz98Gtg5CR5iySsZSnYQ/NhOe2E/Owzra52Zsw LR5RVJYQaW30ar6ROlxzWjMMon2izaNKkoBNkKW9B+fqMqEkH10ywM9yuu91XL4= =fBY0 -----END PGP SIGNATURE----- --9mhhWTN505svsWvIGSdubOCnmmpnIitak--