The channels list was not protected by a lock in red_client_destroy. This could cause for instance a RedChannelClient object to be created while scanning the list so potentially modifying the list while scanning with all race issues.
Consider a client which attempt to connect to a new channel and then for some reason close the main channel:- the new channel connection is handled by the main thread;- the relative RCC will be passed to red_channel_connect which can decide to continue the initialization in another thread (this happens currently for CursorChannelClient and DisplayChannelClient);- the main thread will catch the main channel disconnection and call main_dispatcher_client_disconnect (from main_channel_client_on_disconnect);- main thread calls reds_client_disconnect;- reds_client_disconnect calls red_client_destroy;- now we have 2 thread which will attempt to change RedClient::channels list, one protected by the mutex the other not.
f4a387f6 red-client: Protect concurrent list accesses
server/red-client.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)