about summary refs log tree commit diff
path: root/src/thread/pthread_mutex_destroy.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2012-08-17 17:13:53 -0400
committerRich Felker <dalias@aerifal.cx>2012-08-17 17:13:53 -0400
commitda8d0fc4fa3490f418a438b7e0830f9af312d41f (patch)
tree2faddbd4253ce4cc0ef9f9216fce451d2f9b9c47 /src/thread/pthread_mutex_destroy.c
parent11458e5b098319cf3e2d05c8cbaa74d58db740e3 (diff)
downloadmusl-da8d0fc4fa3490f418a438b7e0830f9af312d41f.tar.gz
musl-da8d0fc4fa3490f418a438b7e0830f9af312d41f.tar.xz
musl-da8d0fc4fa3490f418a438b7e0830f9af312d41f.zip
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.
Diffstat (limited to 'src/thread/pthread_mutex_destroy.c')
0 files changed, 0 insertions, 0 deletions