From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buJVA-0005nr-Lu for qemu-devel@nongnu.org; Wed, 12 Oct 2016 09:23:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buJV4-0007g4-Ib for qemu-devel@nongnu.org; Wed, 12 Oct 2016 09:23:19 -0400 Received: from 7.mo179.mail-out.ovh.net ([46.105.61.94]:54003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buJV4-0007fX-CR for qemu-devel@nongnu.org; Wed, 12 Oct 2016 09:23:14 -0400 Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 8C953FFC89C for ; Wed, 12 Oct 2016 15:23:13 +0200 (CEST) Date: Wed, 12 Oct 2016 15:23:08 +0200 From: Greg Kurz Message-ID: <20161012152308.5549fa32@bahia> In-Reply-To: <20161010105603.132a5d53@bahia> References: <6aefc5ee17ba6ac636de56bba8e7f24fd0262187.1475990063.git.liqiang6-s@360.cn> <20161010105603.132a5d53@bahia> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Li Qiang Cc: Li Qiang , qemu-devel@nongnu.org On Mon, 10 Oct 2016 10:56:03 +0200 Greg Kurz wrote: > On Sat, 8 Oct 2016 22:26:51 -0700 > Li Qiang wrote: > > > From: Li Qiang > > > > 9pfs uses g_malloc() to allocate the xattr memory space, if the guest > > reads this memory before writing to it, this will leak host heap memory > > to the guest. This patch avoid this. > > > > Signed-off-by: Li Qiang > > --- > > I've looked again and we could theorically defer allocation until > v9fs_xattr_write() is called, and only allow v9fs_xattr_read() to > return bytes previously written by the client. But this would > result in rather complex code to handle partial writes and reads. > > So this patch looks like the way to go. > > Reviewed-by: Greg Kurz > 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. Since this is yet another issue, I suggest you send another patch on top of this one... and maybe check other locations in the code where this could happen. Cheers. -- Greg > > hw/9pfs/9p.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index 119ee58..8751c19 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -3282,7 +3282,7 @@ static void v9fs_xattrcreate(void *opaque) > > xattr_fidp->fs.xattr.flags = flags; > > v9fs_string_init(&xattr_fidp->fs.xattr.name); > > v9fs_string_copy(&xattr_fidp->fs.xattr.name, &name); > > - xattr_fidp->fs.xattr.value = g_malloc(size); > > + xattr_fidp->fs.xattr.value = g_malloc0(size); > > err = offset; > > put_fid(pdu, file_fidp); > > out_nofid: > >