Description
Issue: Potential Deadlock in GWP-ASan Signal Handler When Handling Recursive Memory Access Violations
Summary
In specific scenarios involving signal handling during memory operations, GWP-ASan's signal handler can enter a deadlock state when attempting to acquire locks that are already held by the interrupted thread. This occurs when a UAF (Use-After-Free) violation happens within a signal handler while the main thread holds GWP-ASan's internal locks.
Detailed Description
Consider the following scenario in a single-threaded application using GWP-ASan for all memory operations:
- Program A registers a signal handler b
- Program A performs a memory allocation operation, during which it acquires GWP-ASan's internal lock(s)，While holding the lock(s), a signal is delivered and the program enters signal handler b
- Within signal handler b, a UAF violation occurs, triggering GWP-ASan's segv_handler
- The segv_handler attempts to acquire the same lock(s) already held by the main thread
Since GWP-ASan uses non-recursive locks (normal mutexes), the lock acquisition in the signal handler will block indefinitely, causing a deadlock. The program hangs without producing a diagnostic report.
I noticed that in this MR 35b5499, @hctim changed trylock() to lock() in GWP_ASan's signal handler. hctim, have you considered the potential deadlock scenario this might cause?