diff options
author | Rich Felker <dalias@aerifal.cx> | 2012-08-17 17:13:53 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2012-08-17 17:13:53 -0400 |
commit | da8d0fc4fa3490f418a438b7e0830f9af312d41f (patch) | |
tree | 2faddbd4253ce4cc0ef9f9216fce451d2f9b9c47 /src/thread/pthread_mutex_destroy.c | |
parent | 11458e5b098319cf3e2d05c8cbaa74d58db740e3 (diff) | |
download | musl-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