summaryrefslogtreecommitdiff
path: root/libc/malloc_hooks/malloc_hooks.cpp
diff options
context:
space:
mode:
authorAdrian-CJ Hung <adrian-cj.hung@mediatek.com>2019-04-03 10:39:15 +0800
committerJeiFeng Lee <linger.lee@mediatek.com>2019-04-03 11:50:33 +0800
commit8c1a14d4f358a8135e0c0632da6d40c37192c0c2 (patch)
treeaf9be5a543c0192df1cccedaac674d06bc809f5e /libc/malloc_hooks/malloc_hooks.cpp
parentb656d4a1da35eac817950f906ce1c26259c05e82 (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