[jira] [Comment Edited] (GUACAMOLE-1053) guacd segfaults when user actively presses keys at RDP disconnect time

["Grigory Trenin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092412#comment-17092412 ] 

Grigory Trenin edited comment on GUACAMOLE-1053 at 4/30/20, 6:46 PM:
---------------------------------------------------------------------

I managed to reproduce it and updated the original issue. I will close my pull request [#272|https://github.com/apache/guacamole-server/pull/272] and create another one to fix race condition.


was (Author: trengri):
Yes, it happened only twice in a production environment, and I was unable to reproduce it in test, though I tried hard. This lead me to source code analysis, which I presented in this issue. I have also raised a pull request [#272|https://github.com/apache/guacamole-server/pull/272].

> guacd segfaults when user actively presses keys at RDP disconnect time
> ----------------------------------------------------------------------
>
>                 Key: GUACAMOLE-1053
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1053
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacd
>    Affects Versions: 1.1.0
>         Environment: RHEL 7.7 (x86_64)
>            Reporter: Grigory Trenin
>            Priority: Minor
>
> {noformat}
> Program terminated with signal 11, Segmentation fault.
> #0  guac_rdp_keyboard_update_keysym (keyboard=0x7faa4c364010, keysym=65288, pressed=0) at keyboard.c:444
> 444         if (!keyboard->synchronized) {
> (gdb) p keyboard->synchronized
> Cannot access memory at address 0x7faa4c36401c
> (gdb) bt
> #0  guac_rdp_keyboard_update_keysym (keyboard=0x7faa4c364010, keysym=65288, pressed=0) at keyboard.c:444
> #1  0x00007faae2f50bf0 in guac_user_input_thread (data=<optimized out>) at user-handshake.c:165
> #2  0x00007faae2372ea5 in start_thread () from /lib64/libpthread.so.0
> #3  0x00007faae0c678cd in clone () from /lib64/libc.so.6
> (gdb) info threads
>   Id   Target Id         Frame
>   3    Thread 0x7fa9eb7fe700 (LWP 7379) 0x00007faae2374017 in pthread_join () from /lib64/libpthread.so.0
>   2    Thread 0x7fa9ebfff700 (LWP 7376) (Exiting) 0x00007faae2379bad in recvmsg () from /lib64/libpthread.so.0
> * 1    Thread 0x7fa9f8ff9700 (LWP 7381) guac_rdp_keyboard_update_keysym (keyboard=0x7faa4c364010, keysym=65288, pressed=0)
>     at keyboard.c:444
> {noformat}
> "info threads" shows that there are only 3 threads running:
>  # guac_user_input_thread (the thread segfault occured in)
>  # guacd_connection_thread
>  # guacd_user_thread waiting for guac_user_input_thread
> Note that there is no client thread running.
>  So here is what happenned: *guac_rdp_client_thread* exited and freed *rdp_client->keyboard* structure, while user input thread was still running and tried to access *rdp_client->keyboard* after it was freed.
> This is an old bug. Found a 2-year old GUACAMOLE-433 which looks exactly the same, but it was closed as "Cannot reproduce". It does not happen often indeed. We have 120 users actively using Guacamole (since COVID-19) and have seen this segfault only twice within the last month.
> After some research I managed to reliably reproduce it.
> It is reproducable with 1.1.0, staging/1.2.0 and master branches.
> Steps to reproduce:
>  # Connect to RDP server
>  # Block connnection to RDP server with iptables (or create conditions for disconnect in any other way):
> {noformat}
> iptables -A OUTPUT -d <RDP_SERVER_ADDRESS> -j REJECT{noformat}
>  # Use keyboard or mouse actively. The easiest way is to push some key and hold it down for 30-60 seconds.
>  # Segmentation fault will happen in next 30-60 seconds at RDP disconnect time.
>  # Release the key you kept pressing
> Segmentation fault can happen in multiple places depending on what you were doing at the time of disconnect, but typically it happens in keyboard or mouse handlers.
>  Since it is a race between threads, you may have to make several attempts to reproduce it.
>  I found it easily reproducable on a VM with a single CPU core, but on a physical machine with 24 CPU cores I had to make 3 or 4 attempts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)