qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Klim Kireev <klim.kireev@virtuozzo.com>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] vnc: fix segfault in closed connection handling
Date: Wed, 31 Jan 2018 16:44:58 +0000	[thread overview]
Message-ID: <20180131164458.GN3255@redhat.com> (raw)
In-Reply-To: <20180131162521.31210-1-klim.kireev@virtuozzo.com>

On Wed, Jan 31, 2018 at 07:25:21PM +0300, Klim Kireev wrote:
> On one of our client's node, due to trying to read from closed ioc,
> a segmentation fault occured. Corresponding backtrace:
> 
> 0  object_get_class (obj=obj@entry=0x0)
> 1  qio_channel_readv_full (ioc=0x0, iov=0x7ffe55277180 ...
> 2  qio_channel_read (ioc=<optimized out> ...
> 3  vnc_client_read_buf (vs=vs@entry=0x55625f3c6000, ...
> 4  vnc_client_read_plain (vs=0x55625f3c6000)
> 5  vnc_client_read (vs=0x55625f3c6000)
> 6  vnc_client_io (ioc=<optimized out>, condition=G_IO_IN, ...
> 7  g_main_dispatch (context=0x556251568a50)
> 8  g_main_context_dispatch (context=context@entry=0x556251568a50)
> 9  glib_pollfds_poll ()
> 10 os_host_main_loop_wait (timeout=<optimized out>)
> 11 main_loop_wait (nonblocking=nonblocking@entry=0)
> 12 main_loop () at vl.c:1909
> 13 main (argc=<optimized out>, argv=<optimized out>, ...
> 
> Having analyzed the coredump, I understood that the reason is that
> ioc_tag is reset on vnc_disconnect_start and ioc is cleaned
> in vnc_disconnect_finish. Between these two events due to some
> reasons the ioc_tag was set again and after vnc_disconnect_finish
> the handler is running with freed ioc,
> which led to the segmentation fault.
> 
> The patch checks vs->disconnecting in places where we call
> qio_channel_add_watch to prevent such an occurrence.
> 
> Signed-off-by: Klim Kireev <klim.kireev@virtuozzo.com>
> ---
> Changelog:
> v2: Attach the backtrace
> 
> v3: Change checks
> 
>  ui/vnc.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/ui/vnc.c b/ui/vnc.c
> index 33b087221f..708204fa7e 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -1407,13 +1407,19 @@ static void vnc_client_write_locked(VncState *vs)
>      } else
>  #endif /* CONFIG_VNC_SASL */
>      {
> -        vnc_client_write_plain(vs);
> +        if (vs->disconnecting == FALSE) {
> +            vnc_client_write_plain(vs);
> +        } else {
> +            if (vs->ioc_tag != 0) {
> +                g_source_remove(vs->ioc_tag);
> +                vs->ioc_tag = 0;
> +            }
> +        }
>      }
>  }

I'm not sure it is safe to only do the check in the else{} branch
of this code. If this code is reachable, then I think the SASL
branch will cause the same crash problems too.  I think probably
need to push the checks up a level or two in the caller stack...

>  
>  static void vnc_client_write(VncState *vs)
>  {
> -
>      vnc_lock_output(vs);
>      if (vs->output.offset) {
>          vnc_client_write_locked(vs);
> @@ -1421,8 +1427,12 @@ static void vnc_client_write(VncState *vs)
>          if (vs->ioc_tag) {
>              g_source_remove(vs->ioc_tag);
>          }
> -        vs->ioc_tag = qio_channel_add_watch(
> -            vs->ioc, G_IO_IN, vnc_client_io, vs, NULL);
> +        if (vs->disconnecting == FALSE) {
> +            vs->ioc_tag = qio_channel_add_watch(
> +                vs->ioc, G_IO_IN, vnc_client_io, vs, NULL);
> +        } else {
> +            vs->ioc_tag = 0;
> +        }
>      }
>      vnc_unlock_output(vs);
>  }

...I think perhaps we should do the check in the vnc_client_io()
method, and also in the vnc_flush() method.

I think we also need to put a check in the vnc_jobs_consume_buffer()
method, which can be triggered from a bottom-half.


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 :|

  reply	other threads:[~2018-01-31 16:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31 16:25 [Qemu-devel] [PATCH v2] vnc: fix segfault in closed connection handling Klim Kireev
2018-01-31 16:44 ` Daniel P. Berrangé [this message]
2018-02-07  8:42   ` klim
2018-02-07  9:00     ` klim
  -- strict thread matches above, loose matches on Subject: below --
2018-01-31 13:15 Klim Kireev
2018-01-31 13:22 ` Daniel P. Berrangé

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=20180131164458.GN3255@redhat.com \
    --to=berrange@redhat.com \
    --cc=klim.kireev@virtuozzo.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).