id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
8538,asio: race condition for epoll & kpoll,Leonid Gershanovich <gleonid@…>,chris_kohlhoff,"Please consider following code in boost\asio\detail\impl\epoll_reactor.ipp:


{{{
345: void epoll_reactor::deregister_internal_descriptor(socket_type descriptor,
346:     epoll_reactor::per_descriptor_data& descriptor_data)
347: {
...
351:     mutex::scoped_lock descriptor_lock(descriptor_data->mutex_);
...
365:     descriptor_lock.unlock();
366:     free_descriptor_state(descriptor_data);
367:     descriptor_data = 0;
368: }
}}}
Lets assume, that ''thread 1'' executes epoll_reactor::deregister_internal_descriptor and successfully acquired lock (descriptor_data->mutex_), while ''thread 2'' is waiting to acquire same lock in this or different function (epoll_reactor::start_op, epoll_reactor::cancel_ops).

As soon as ''thread 1'' executes '''descriptor_lock.unlock'''(); on line 365, ''thread 2'' will acquire descriptor_data->mutex_ it was waiting for.

At this point ''thread 1'' executes '''free_descriptor_state''' (line 366) effectively destroying mutex, which means that when ''thread 2'' will attempt to release mutex, as part of mutex::scoped_lock dtor, it might seg fault, because memory used for mutex already might have been allocated for something else by ''thread 1''.


Above I quoted code fragment from ''epoll_reactor::deregister_internal_descriptor'', but exactly same issue is present in void ''epoll_reactor::deregister_descriptor''.

I am attaching complete patch to this ticket.

Furthermore,
looks like same problem present in boost\asio\detail\impl\kqueue_reactor.ipp.

Since I am building on Linux and not building kqueue facility I cannot provided validate patch for that, but I suspect it will be very similar to epoll's one.",Bugs,closed,To Be Determined,asio,Boost 1.53.0,Problem,invalid,,