Closed doadam closed 1 year ago
@doadam can you provide any information on how you duplicated this? It seems to be the same issue as the UAF reported in #8 but I have not been able to duplicate either one, and the logic should have cleared remote->client
before
if (client->remote) {
usbmux_remote_notify_client_close(client->remote); // this takes the lock
}
at
client_remote_unset(remote); <-- *here*
if (remote->client) {
client_notify_remote_close(remote->client); // here
}
at which point this would not be a deadlock
This should now have the fix verified with doadam in source master (v1.2.1) will be updating binary release soon.
usbmux_remote_process
takes a lock onremote_list_mutex
when checking for remotes that need to be removed:However,
usbmux_remote_dispose
will ultimately callclient_close
which takes the lock as well viausbmux_remote_notify_client_close
:This will cause usbfluxd to hang after a while. I fixed it by changing
remote_list_mutex
to be recursive. A patch is attached as well.Tested on 0723a9a89a188de0949a6c80177705309ebb21f5, which is master at the time of writing. fix_deadlock.patch