[Boost-bugs] [Boost C++ Libraries] #8538: asio: race condition for epoll & kpoll

Subject: [Boost-bugs] [Boost C++ Libraries] #8538: asio: race condition for epoll & kpoll
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-05-01 20:36:39


#8538: asio: race condition for epoll & kpoll
-----------------------------------------------------+----------------------
 Reporter: Leonid Gershanovich <gleonid@…> | Type: Bugs
   Status: new | Milestone: To Be Determined
Component: None | Version: Boost 1.53.0
 Severity: Problem | Keywords:
-----------------------------------------------------+----------------------
 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8538>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:13 UTC