diff options
author | Adrian-CJ Hung <adrian-cj.hung@mediatek.com> | 2019-04-03 10:39:15 +0800 |
---|---|---|
committer | JeiFeng Lee <linger.lee@mediatek.com> | 2019-04-03 11:50:33 +0800 |
commit | 8c1a14d4f358a8135e0c0632da6d40c37192c0c2 (patch) | |
tree | af9be5a543c0192df1cccedaac674d06bc809f5e /libc/malloc_hooks/malloc_hooks.cpp | |
parent | b656d4a1da35eac817950f906ce1c26259c05e82 (diff) |
Workaround potential access to unmapped stack
Issue:
Process is crashed near the end (startup_handshake_lock.unlock()) in
pthread_create().
The newly created child thread passes this handshake_lock unexpectedly
=> its stack is unmapped & its associated pthread_internal_t data
structure can’t be accessed.
Analysis:
The created child thread should be blocked by startup_handshake_lock.lock()
and enter __futex_wait_ex()
But if the parent thread is in the middle of startup_handshake_lock.unlock():
void unlock() {
if (atomic_exchange_explicit(&state, Unlocked, memory_order_seq_cst) == LockedWithWaiter) { // => the state is modified to Unlocked
// (a) if the child thread is back to running and pass the while() check in Lock::lock()
// (b) the child thread executes its start_routine and then pthread_exit
// (c) the stack of the child thread (where its pthread_internal_t (so the startup_handshake_lock) is located) will be unmapped
__futex_wake_ex(&state, process_shared, 1); // => when the parent thread is back to running
// the “state” & “process_shared” of startup_handshake_lock can’t be accessed (unmapped)
// so the process will be crashed
}
}
Bug: 129744706
Test: Monkey
Change-Id: I55175e8c7ebc2b3b52de8a5602def0667076b974
Diffstat (limited to 'libc/malloc_hooks/malloc_hooks.cpp')
0 files changed, 0 insertions, 0 deletions