path: root/src
diff options
authorRich Felker <>2020-11-19 16:20:45 -0500
committerRich Felker <>2020-11-19 16:36:49 -0500
commit233bb6972d84e9cb908ff038f78d97e487082225 (patch)
treea830437037601507b71899161e1af8d8ea703ad6 /src
parentd26e0774a59bb7245b205bc8e7d8b35cc2037095 (diff)
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.
Diffstat (limited to 'src')
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;