diff options
author | Rich Felker <dalias@aerifal.cx> | 2020-11-19 16:20:45 -0500 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2020-11-19 16:36:49 -0500 |
commit | 233bb6972d84e9cb908ff038f78d97e487082225 (patch) | |
tree | a830437037601507b71899161e1af8d8ea703ad6 | |
parent | d26e0774a59bb7245b205bc8e7d8b35cc2037095 (diff) | |
download | musl-233bb6972d84e9cb908ff038f78d97e487082225.tar.gz musl-233bb6972d84e9cb908ff038f78d97e487082225.tar.bz2 musl-233bb6972d84e9cb908ff038f78d97e487082225.tar.xz musl-233bb6972d84e9cb908ff038f78d97e487082225.zip |
protect destruction of process-shared mutexes against robust list races
after a non-normal-type process-shared mutex is unlocked, it's
immediately available to another thread to lock, unlock, and destroy,
but the first unlocking thread may still have a pointer to it in its
robust_list pending slot. this means, on async process termination,
the kernel may attempt to access and modify the memory that used to
contain the mutex -- memory that may have been reused for some other
purpose after the mutex was destroyed.
setting up for this kind of race to occur is difficult to begin with,
requiring dynamic use of shared memory maps, and actually hitting the
race is very difficult even with a suitable setup. so this is mostly a
theoretical fix, but in any case the cost is very low.
-rw-r--r-- | src/thread/pthread_mutex_destroy.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/src/thread/pthread_mutex_destroy.c b/src/thread/pthread_mutex_destroy.c index 6d49e689..8d1bf77b 100644 --- a/src/thread/pthread_mutex_destroy.c +++ b/src/thread/pthread_mutex_destroy.c @@ -1,6 +1,10 @@ -#include <pthread.h> +#include "pthread_impl.h" int pthread_mutex_destroy(pthread_mutex_t *mutex) { + /* If the mutex being destroyed is process-shared and has nontrivial + * type (tracking ownership), it might be in the pending slot of a + * robust_list; wait for quiescence. */ + if (mutex->_m_type > 128) __vm_wait(); return 0; } |