offensive-security
A possible communication deadlock due to the lost notify
Hi, it seems there is a potential deadlock bug in exploitdb between the below signals and waiting sites, because it is possible for the thread to signal first and, later, the thread goes to the waiting site forever without signal notified anymore. (The happens-before order between the wait and signal is not enforced.)
wait sites https://github.com/offensive-security/exploitdb/blob/b4c96a5864acae22f1b7a23e3214abcf06656c7d/exploits/linux/local/35370.c#L428-L436
https://github.com/offensive-security/exploitdb/blob/b4c96a5864acae22f1b7a23e3214abcf06656c7d/exploits/linux/local/35370.c#L628-L631
notify sites https://github.com/offensive-security/exploitdb/blob/b4c96a5864acae22f1b7a23e3214abcf06656c7d/exploits/linux/local/35370.c#L380-L382
https://github.com/offensive-security/exploitdb/blob/b4c96a5864acae22f1b7a23e3214abcf06656c7d/exploits/linux/local/35370.c#L393-L395
To avoid this problem, the recommended usage of thread_cond_signal and thread_cond_wait would be
pthread_mutex_t count_lock;
pthread_cond_t count_nonzero;
unsigned count;
decrement_count()
{
pthread_mutex_lock(&count_lock);
while (count == 0)
pthread_cond_wait(&count_nonzero, &count_lock);
count = count - 1;
pthread_mutex_unlock(&count_lock);
}
increment_count()
{
pthread_mutex_lock(&count_lock);
if (count == 0)
pthread_cond_signal(&count_nonzero);
count = count + 1;
pthread_mutex_unlock(&count_lock);
}
Sorry for the delay. Thank you for the bug report - however its best to contact the author to have it added to their code so we can import it. Its not yet possible todo two way git merges upstream to our database.
