race condition fix: block all signals before decrementing thread count
the existence of a (kernelspace) thread must never have observable effects after the thread count is decremented. if signals are not blocked, it could end up handling the signal for rsyscall and contributing towards the count of threads which have changed ids, causing a thread to be missed. this could lead to one thread retaining unwanted privilege level. this change may also address other subtle race conditions in application code that uses signals.
This commit is contained in:
parent
a49c119276
commit
19eb13b9a4
3 changed files with 2 additions and 22 deletions
|
|
@ -25,6 +25,8 @@ void __pthread_unwind_next(struct __ptcb *cb)
|
|||
}
|
||||
}
|
||||
|
||||
syscall4(__NR_sigprocmask, SIG_BLOCK, (long)(uint64_t[1]){-1}, 0, 8);
|
||||
|
||||
if (!a_fetch_add(&libc.threads_minus_1, -1))
|
||||
exit(0);
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue