On Wed, 12 Oct 2016 15:49:46 -0500 Eric Blake <ebl...@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
pgpUPo0OeukPa.pgp
Description: OpenPGP digital signature