[stunnel-users] Race condition in libwrap_auth can hang threads waiting on libwrap process

[Andrew Skalski]

I ran into an issue with stunnel (verified with the latest version)
where under certain conditions, client connections will hang in the
"Waiting for a libwrap process" state.

The problem is a race condition in src/libwrap.c:

170         --num_busy; /* the child process has been released */
171         if(num_busy==num_processes-1) { /* need to wake up a thread */
172             retval=pthread_cond_signal(&cond); /* signal waiting threads */
173             if(retval) {
174                 errno=retval;
175                 ioerror("pthread_cond_signal");
176                 longjmp(c->err, 1);
177             }
178         }

Removing the statement "if (num_busy==num_processes-1)" is one way to
fix the problem.

The conditions under which the race condition occur are:
  - All libwrap processes are busy, and multiple threads are waiting
[num_busy == num_processes]
  - One thread releases its libwrap process (this signals one of the
waiting threads)
  - Another thread releases its libwrap process before the signaled
thread has a chance to acquire and increment num_busy.

Once that happens, all queued threads are stuck waiting on the
condition variable, until stunnel is hit with enough concurrent
connections to max out num_busy again.  (Depending on traffic
patterns, this may not happen for a long time.)

Andy Skalski