fix extremely rare but dangerous race condition in robust mutexes

if new shared mappings of files/devices/shared memory can be made
between the time a robust mutex is unlocked and its subsequent removal
from the pending slot in the robustlist header, the kernel can
inadvertently corrupt data in the newly-mapped pages when the process
terminates. i am fixing the bug by using the same global vm lock
mechanism that was used to fix the race condition with unmapping
barriers after pthread_barrier_wait returns.

1 files changed, 7 insertions, 1 deletions

diff --git a/src/thread/pthread_mutex_unlock.c b/src/thread/pthread_mutex_unlock.c
index fdf9fc10..5fc0f4e5 100644
--- a/src/thread/pthread_mutex_unlock.c
+++ b/src/thread/pthread_mutex_unlock.c
@@ -1,5 +1,8 @@
 #include "pthread_impl.h"
 
+void __vm_lock_impl(int);
+void __vm_unlock_impl(void);
+
 int pthread_mutex_unlock(pthread_mutex_t *m)
 {
 	pthread_t self;
@@ -20,11 +23,14 @@ int pthread_mutex_unlock(pthread_mutex_t *m)
 			self->robust_list.pending = &m->_m_next;
 			*(void **)m->_m_prev = m->_m_next;
 			if (m->_m_next) ((void **)m->_m_next)[-1] = m->_m_prev;
+			__vm_lock_impl(+1);
 		}
 	}
 	cont = a_swap(&m->_m_lock, 0);
-	if (robust)
+	if (robust) {
 		self->robust_list.pending = 0;
+		__vm_unlock_impl();
+	}
 	if (waiters || cont<0)
 		__wake(&m->_m_lock, 1, 0);
 	return 0;