Re: [Qemu-devel] [PATCH 1/2] 9pfs: fix information leak in xattr read

[Greg Kurz <groug@kaod.org>]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Wed, 12 Oct 2016 15:49:46 -0500
Eric Blake <eblake@redhat.com> wrote:

> On 10/12/2016 08:23 AM, Greg Kurz wrote:
> > 
> > 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.  
> 
> 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.
> 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]