summaryrefslogtreecommitdiffstats
path: root/xlators/features/bit-rot
diff options
context:
space:
mode:
authorXavi Hernandez <xhernandez@redhat.com>2019-12-19 11:58:54 +0100
committerAmar Tumballi <amarts@gmail.com>2019-12-27 04:08:09 +0000
commit77c48f77a9e7bfa202f9a211bacd7e7a9f88ae6b (patch)
tree49ca55603bd1c3f4367424c9fbafdb972328f5c5 /xlators/features/bit-rot
parent6350695dccfafdd6ab22be3509ade549a34db98b (diff)
timer: fix event destruction race
In current timer implementation, each event has an absolute time at which it will be fired. When the first timer of the queue has not elapsed yet, a pthread_cond_timedwait() is used to wait until the expected time. Apparently that's fine. However the time passed to that function was a pointer to the timespec structure contained in the event itself. This is problematic because of how pthread_cond_timedwait() works internally. Simplifying a bit, pthread_cond_timedwait() basically queues itself as a waiter for the given condition variable and releases the mutex. Then it does the timed wait using the passed value. With that in mind, the follwing case is possible: Timer Thread Other Thread ------------ ------------ gf_timer_call_cancel() pthread_mutex_lock() | + pthread_mutex_lock() event = current_event() | pthread_cond_timedwait(&event->at) | + pthread_mutex_unlock() | | + remove_event() | + destroy_event() + timed_wait(&event->at) As we can see, the time is used after it has been destroyed, which means we have a use-after-free problem. This patch fixes the problem by copying the time to a local variable before calling pthread_cond_timedwait() Change-Id: I0f4e8eded24fe3a1276dc75c6cf093bae973d26b Signed-off-by: Xavi Hernandez <xhernandez@redhat.com> Fixes: bz#1785208
Diffstat (limited to 'xlators/features/bit-rot')
0 files changed, 0 insertions, 0 deletions