[Qemu-devel] Guest crash when VNC connection is established with password (QEMU 2.5.1.1)

[Qemu-devel] Guest crash when VNC connection is established with password (QEMU 2.5.1.1)

[John Y.]

(Sorry for repost,  I had asked in qemu-stable, but someone told me that I
should send to qemu-devel.)

After I updated my Centos to 7.5.1804, my virtual machine crashed when I
connected with vnc password.

*1. My problem：*

Here  what I tested:
(1).  started a guest with : qemu-system-x86_64 -m 2048 test.img -vnc
0.0.0.0:3 <http://0.0.0.0:7>,password -monitor stdio
(2). change password to 1234567.
(3). connected with VncViewer

Here was the output:

# qemu-system-x86_64 -m 2048 test.img -vnc 0.0.0.0:3,password -monitor stdio
> QEMU 2.5.1.1 monitor - type 'help' for more information
> (qemu) change vnc password 12345678
> (qemu) Segmentation fault
>

I  debugged with gdb and got:

> (qemu) change vnc password 12345678
> (qemu)
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff528cc80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> (gdb) bt
> #0  0x00007ffff528cc80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1  0x0000555555a97f4a in qemu_mutex_lock (mutex=0x0) at
> util/qemu-thread-posix.c:73
> #2  0x0000555555a5cce3 in qcrypto_gcrypt_mutex_lock (priv=0x7ffff6e90ca0)
> at crypto/init.c:97
> #3  0x00007ffff6c217c5 in mutex_init () from /lib64/libgcrypt.so.11
> #4  0x00007ffff6c21baa in _gcry_ath_mutex_lock () from
> /lib64/libgcrypt.so.11
> #5  0x00007ffff6c5ad20 in lock_pool () from /lib64/libgcrypt.so.11
> #6  0x00007ffff6c5be2e in _gcry_rngcsprng_fast_poll () from
> /lib64/libgcrypt.so.11
> #7  0x00007ffff6c23d4d in _gcry_cipher_open () from /lib64/libgcrypt.so.11
> #8  0x0000555555a60251 in qcrypto_cipher_new
> (alg=QCRYPTO_CIPHER_ALG_DES_RFB, mode=QCRYPTO_CIPHER_MODE_ECB,
> key=0x7fffffffdf30 "12345678\020", nkey=8, errp=0x7fffffffdf08) at
> ./crypto/cipher-gcrypt.c:97
> #9  0x00005555559d8912 in protocol_client_auth_vnc (vs=0x5555565b5660,
> data=0x555557a6c0a0 "\036\352\"s٘\373\345<ܯ\210L\b;$\220\300\246WUU",
> len=16) at ui/vnc.c:2551
> #10 0x00005555559d60b5 in vnc_client_read (opaque=0x5555565b5660) at
> ui/vnc.c:1564
> #11 0x0000555555a046a7 in aio_dispatch (ctx=0x555556508790) at
> aio-posix.c:326
> #12 0x00005555559f4166 in aio_ctx_dispatch (source=0x555556508790,
> callback=0x0, user_data=0x0) at async.c:231
> #13 0x00007ffff5f10969 in g_main_context_dispatch () from
> /lib64/libglib-2.0.so.0
> #14 0x0000555555a026e7 in glib_pollfds_poll () at main-loop.c:211
> #15 0x0000555555a027c4 in os_host_main_loop_wait (timeout=54752182) at
> main-loop.c:256
> #16 0x0000555555a02874 in main_loop_wait (nonblocking=0) at main-loop.c:504
> #17 0x00005555558251c1 in main_loop () at vl.c:1923
> #18 0x000055555582cbe5 in main (argc=8, argv=0x7fffffffe558,
> envp=0x7fffffffe5a0) at vl.c:4699
>


*2.  Other Infomation*
(1).  Version of qemu:
QEMU emulator version 2.5.1.1, Copyright (c) 2003-2008 Fabrice Bellard

(2).  kernel and os：
kernel : 4.16.3-1.el7.elrepo.x86_64
os: CentOS Linux release 7.5.1804 (Core)

(3).  I had try /usr/libexec/qemu-kvm(qemu-kvm-1.5.3-156.el7_5.5)  and qemu
2.11, both of them worked fine.

(4).  Has no problem witout vnc password.

(5). I update my host with yum update.

(6).  Everything work find before update.

*3.  My Question*
For some reasons I have to use qemu 2.5.11 and update Centos.
(1) What causes this problem and how can I solve it ?

Looking forward to your reply.

Regards,
John

Re: [Qemu-devel] Guest crash when VNC connection is established with password (QEMU 2.5.1.1)

[Daniel P. Berrangé]

On Tue, Aug 28, 2018 at 09:01:24AM +0800, John Y. wrote:
> (Sorry for repost,  I had asked in qemu-stable, but someone told me that I
> should send to qemu-devel.)
> 
> After I updated my Centos to 7.5.1804, my virtual machine crashed when I
> connected with vnc password.

[snip]

> > (qemu) change vnc password 12345678
> > (qemu)
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00007ffff528cc80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> > (gdb) bt
> > #0  0x00007ffff528cc80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> > #1  0x0000555555a97f4a in qemu_mutex_lock (mutex=0x0) at
> > util/qemu-thread-posix.c:73
> > #2  0x0000555555a5cce3 in qcrypto_gcrypt_mutex_lock (priv=0x7ffff6e90ca0)
> > at crypto/init.c:97
> > #3  0x00007ffff6c217c5 in mutex_init () from /lib64/libgcrypt.so.11
> > #4  0x00007ffff6c21baa in _gcry_ath_mutex_lock () from
> > /lib64/libgcrypt.so.11
> > #5  0x00007ffff6c5ad20 in lock_pool () from /lib64/libgcrypt.so.11
> > #6  0x00007ffff6c5be2e in _gcry_rngcsprng_fast_poll () from
> > /lib64/libgcrypt.so.11
> > #7  0x00007ffff6c23d4d in _gcry_cipher_open () from /lib64/libgcrypt.so.11
> > #8  0x0000555555a60251 in qcrypto_cipher_new
> > (alg=QCRYPTO_CIPHER_ALG_DES_RFB, mode=QCRYPTO_CIPHER_MODE_ECB,
> > key=0x7fffffffdf30 "12345678\020", nkey=8, errp=0x7fffffffdf08) at
> > ./crypto/cipher-gcrypt.c:97

THis crash is caused by missing init of gcrypt. It is fixed in QEMU 2.8.0
with

commit 373166636b9f07c60d7c32610bd346acf7d143e9 (tag: pull-qcrypto-2016-10-20-1)
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon Oct 10 12:17:50 2016 +0100

    crypto: fix initialization of gcrypt threading
    
    The gcrypt threads implementation must be set before calling
    any other gcrypt APIs, especially gcry_check_version(),
    since that triggers initialization of the random pool. After
    that is initialized, changes to the threads impl won't be
    honoured by the random pool code. This means that gcrypt
    will think thread locking is needed and so try to acquire
    the random pool mutex, but this is NULL as no threads impl
    was set originally. This results in a crash in the random
    pool code.
    
    For the same reasons, we must set the gcrypt threads impl
    before calling gnutls_init, since that will also trigger
    gcry_check_version
    
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

> *3.  My Question*
> For some reasons I have to use qemu 2.5.11 and update Centos.
> (1) What causes this problem and how can I solve it ?

Upgrade to a newer QEMU, or backport the above patch (should be easy to
backport)

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