| Issue |
145281
|
| Summary |
[GWP_ASan] Potential Deadlock in GWP-ASan Signal Handler
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
rePeek
|
# 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 https://github.com/llvm/llvm-project/commit/35b5499d7259ac3e5c648a711678290695703a87, @hctim changed trylock() to lock() in GWP_ASan's signal handler. hctim, have you considered the potential deadlock scenario this might cause?
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
