From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buanW-0002ve-FB for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:51:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buanS-0000Hi-9I for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:51:26 -0400 Received: from 6.mo179.mail-out.ovh.net ([46.105.56.76]:32930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buanS-0000Fx-3C for qemu-devel@nongnu.org; Thu, 13 Oct 2016 03:51:22 -0400 Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 2E864FFB967 for ; Thu, 13 Oct 2016 09:51:21 +0200 (CEST) Date: Thu, 13 Oct 2016 09:51:13 +0200 From: Greg Kurz Message-ID: <20161013095113.6626f46a@bahia> In-Reply-To: <62702952-e2d8-fb96-0ed8-94729cd65c4c@redhat.com> References: <6aefc5ee17ba6ac636de56bba8e7f24fd0262187.1475990063.git.liqiang6-s@360.cn> <20161010105603.132a5d53@bahia> <20161012152308.5549fa32@bahia> <62702952-e2d8-fb96-0ed8-94729cd65c4c@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/U4tcw5o0JjneL199Ixy5PVu"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH 1/2] 9pfs: fix information leak in xattr read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Li Qiang , Li Qiang , qemu-devel@nongnu.org --Sig_/U4tcw5o0JjneL199Ixy5PVu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 12 Oct 2016 15:49:46 -0500 Eric Blake wrote: > On 10/12/2016 08:23 AM, Greg Kurz wrote: > >=20 > > But in fact, I'm afraid we have a more serious problem here... size > > comes from the guest and could cause g_malloc() to abort if QEMU has > > reached some RLIMIT... we need to call g_try_malloc0() and return > > ENOMEM if the allocation fails. =20 >=20 > Even if it does not cause an ENOMEM failure right away, the guest can > also use this to chew up lots of host resources. It may also be worth > putting a reasonable cap at the maximum the guest can allocate, rather > than just trying to malloc every possible size. >=20 In the case of v9fs_xattrcreate(), the allocation of the xattr value only happens if a fid with a specific id was created. This function alone cannot be used to chew up memory, but it can certainly be used to crash QEMU if the guest passes an insanely great value. I fully agree that guest triggered allocations should be capped though, and the more I look the more I realize the 9p code is fragile on this matter... This will require more analysis and fixing, which goes far beyond the scope of preventing an immediate crash. Cheers. -- Greg --Sig_/U4tcw5o0JjneL199Ixy5PVu Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlf/PPEACgkQAvw66wEB28IiYACfcD0Q7u20uF8ZktVX1tcgAtnJ LtYAnRDMpl2TU/6ORjTNQz2qX64qSsAl =f4gA -----END PGP SIGNATURE----- --Sig_/U4tcw5o0JjneL199Ixy5PVu--