qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-trivial@nongnu.org, qemu-stable@nongnu.org,
	Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com>,
	qemu-devel@nongnu.org, Sameeh Jubran <sjubran@redhat.com>,
	Basil Salman <basil@daynix.com>
Subject: Re: [PATCH-for-5.0] qga-posix: Avoid crashing process when failing to allocate memory
Date: Mon, 30 Mar 2020 17:25:05 +0100	[thread overview]
Message-ID: <20200330162505.GP236854@redhat.com> (raw)
In-Reply-To: <20200324194836.21539-1-philmd@redhat.com>

On Tue, Mar 24, 2020 at 08:48:36PM +0100, Philippe Mathieu-Daudé wrote:
> Similarly to commit 807e2b6fce0 for Windows, kindly return a
> QMP error message instead of crashing the whole process.
> 
> Cc: qemu-stable@nongnu.org
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1594054

I find that bug report pretty dubious

   "The QEMU Guest Agent in QEMU is vulnerable to an integer 
    overflow in the qmp_guest_file_read(). An attacker could 
    exploit this by sending a crafted QMP command (including 
    guest-file-read with a large count value) to the agent via 
    the listening socket to trigger a g_malloc() call with a 
    large memory chunk resulting in a segmentation fault."

"the attacker" in this case has to have access to the QEMU
chardev associated with the guest agent. IOW, in any sensible
configuration of the chardev, "the attacker" is the same person
who launched QEMU in the first place.  There's no elevation of
privilege here and any denial of service is inflicted against
themselves. Finally it doesn't cause a segmentation fault,
it causes an abort.

This is *NOT* a security bug.

In fact I'd call this NOTABUG entirely. It is just user error
to set the "count" to such a huge value that it hits OOM.

> Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  qga/commands-posix.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index 93474ff770..8f127788e6 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -493,7 +493,13 @@ struct GuestFileRead *qmp_guest_file_read(int64_t handle, bool has_count,
>          gfh->state = RW_STATE_NEW;
>      }
>  
> -    buf = g_malloc0(count+1);
> +    buf = g_try_malloc0(count + 1);
> +    if (!buf) {
> +        error_setg(errp,
> +                   "failed to allocate sufficient memory "
> +                   "to complete the requested service");
> +        return NULL;
> +    }

So you've prevented an OOM when we call fread() on the file.

The contents of 'buf' now need to be turned into JSON which
means the buffer need to be base64 encoded. This will consume
even more memory than the original read.  So checking malloc
here has achieved nothing AFAICT.

>      read_count = fread(buf, 1, count, fh);
>      if (ferror(fh)) {
>          error_setg_errno(errp, errno, "failed to read file");

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      parent reply	other threads:[~2020-03-30 16:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 19:48 [PATCH-for-5.0] qga-posix: Avoid crashing process when failing to allocate memory Philippe Mathieu-Daudé
2020-03-25  6:19 ` Dietmar Maurer
2020-03-25 12:10   ` Philippe Mathieu-Daudé
2020-03-30 14:11     ` Markus Armbruster
2020-03-30 16:04       ` Philippe Mathieu-Daudé
2020-03-30 16:08         ` Philippe Mathieu-Daudé
2020-03-30 16:38         ` Dr. David Alan Gilbert
2020-03-30 16:47           ` Daniel P. Berrangé
2020-03-30 17:06         ` Daniel P. Berrangé
2020-03-31 13:32           ` Philippe Mathieu-Daudé
2020-03-30 16:25 ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200330162505.GP236854@redhat.com \
    --to=berrange@redhat.com \
    --cc=basil@daynix.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mohdfakhrizulkifli@gmail.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=sjubran@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).