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 :|
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.