From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47023)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <liq3ea@gmail.com>) id 1bpAl0-00064N-D1
	for qemu-devel@nongnu.org; Wed, 28 Sep 2016 05:02:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <liq3ea@gmail.com>) id 1bpAku-0008Ly-4p
	for qemu-devel@nongnu.org; Wed, 28 Sep 2016 05:02:25 -0400
Received: from mail-io0-x230.google.com ([2607:f8b0:4001:c06::230]:33908)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <liq3ea@gmail.com>) id 1bpAkt-0008Ls-Up
	for qemu-devel@nongnu.org; Wed, 28 Sep 2016 05:02:20 -0400
Received: by mail-io0-x230.google.com with SMTP id e66so46625156iod.1
	for <qemu-devel@nongnu.org>; Wed, 28 Sep 2016 02:02:19 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20160928104752.2772cbce@bahia>
References: <57e9f923.05acca0a.3dec3.0ccc@mx.google.com>
	<CAKXe6SKvd7Y9bS16SVBt8x+jUD1EZO=izSnqC8NJMtcd5qB-ZA@mail.gmail.com>
	<20160928104752.2772cbce@bahia>
From: Li Qiang <liq3ea@gmail.com>
Date: Wed, 28 Sep 2016 17:02:18 +0800
Message-ID: <CAKXe6SLLXu-3oLCpnyMGThuMe_EpQ4wGA7NEbg6UdQuWL9qRxg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH] 9pfs: fix information leak in xattr read
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Greg Kurz <groug@kaod.org>
Cc: aneesh.kumar@linux.vnet.ibm.com, qemu-devel@nongnu.org, Li Qiang <liqiang6-s@360.cn>

Yes, allocation here is also causing a memory leak issue.
I will try to look more at it.

On 2016-09-28 16:47 GMT+08:00 Greg Kurz <groug@kaod.org> wrote:
>
>
> Heh not exactly... I'm just wondering why we allocate
> xattr_fidp->fs.xattr.value
> here if we don't use it. Can you please investigate if it is possible to
> defer
> allocation until it is really needed ?
>
> Thanks.
>
> --
> Greg
>
> > 2016-09-27 12:44 GMT+08:00 Li Qiang <liq3ea@gmail.com>:
> >
> > > From: Li Qiang <liqiang6-s@360.cn>
> > >
> > > 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 <liqiang6-s@360.cn>
> > > ---
> > >  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 b1ff8e7..4db1bd8 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> > > @@ -3291,7 +3291,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:
> > > --
> > > 1.8.3.1
> > >
> > >
>
>