Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Feb 2020 01:46:34 +0100
From: Sebastian Gottschall <>
Subject: race condition in sem_wait


i discovered recently a race condition while playing with threads and 
sem_wait may fail with errno set EAGAIN which is not valid since only 
sem_trywait is able to set that errno code.
this was causing a bug with a later select() and accept() which failed 
since accept does not work if errno is set to EAGAIN.
from my point of view the bug is in sem_timedwait.c

         if (!sem_trywait(sem)) return 0;

         int spins = 100;
         while (spins-- && sem->__val[0] <= 0 && !sem->__val[1]) a_spin();

         while (sem_trywait(sem)) {

the fist sem_trywait will fail with -1 and sets EAGAIN. but the second 
sem_trywait will not fail and does return 0. the problem now is that 
errno is still present and not reset.
this may cause if sem_post is called from a second thread on the same 
of course the same bug affects sem_timedwait itself.
so i assume sem_wait is not thread safe which is bad and is not follow 
the posix specification

or am i wrong here?


Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.