LibAFL
LibAFL copied to clipboard
AFLplusplus
overflowed sigaltstack
Describe the bug I observed in the kernel log:
[66134.526836] signal: tlspuffin[34092] overflowed sigaltstack
[66134.526838] signal: tlspuffin[34092] overflowed sigaltstack
I'm quite sure this is not related to the programm which I'm fuzzing because its not using signal handlers. I have not been able to reproduce this sofar. Not sure if its serious or just "informational".
To Reproduce Unclear.
Expected behavior No such messages.
Screen output/Screenshots
Additional context
Do you have timeouts/crashes that get handled by restarting the target? These would be handled by signal handlers in the InProcessExecutor. As the state gets dumped to shared map or disk on crash, there is potentially some stack usage here. Maybe try increasing this value and see if the issue goes away?: https://github.com/AFLplusplus/LibAFL/blob/2e746bf439629e4fe8fa47cf9f39acd1395c828f/libafl/src/bolts/os/unix_signals.rs#L402
Not really, there were no events which could have caused that.
Im also unsure whether this is a problem or not. The warning/message has been added recently to kernels (2021).
I'll just close this as its non-reproducible. Weird though.
Hm reopen? That the kernel can log these messages is quite new. So I haven't found a hint whether this is informational or actually bad.
The current signal stack size is 8mb: https://github.com/AFLplusplus/LibAFL/blob/2e746bf439629e4fe8fa47cf9f39acd1395c828f/libafl/src/bolts/os/unix_signals.rs#L354 If it uses the stack to store the complete state, this would of course not be enough after running for a longer time?
I found this in a linux list:
The kernel pushes context on to the userspace stack to prepare for the user's signal handler. When the user has supplied an alternate signal stack, via sigaltstack(2), it is easy for the kernel to verify that the stack size is sufficient for the current hardware context.
Check if writing the hardware context to the alternate stack will exceed it's size. If yes, then instead of corrupting user-data and proceeding with the original signal handler, an immediate SIGSEGV signal is delivered.
In that case we should probably heap allocate the state. Can you think of an example which allows reproduction? Maybe we can will the state artificially.
I could trigger it once with libxml2 but not anymore..sorry. and I lost that fuzzer setup
Please reopen if the issue reoccurs. Closing for now since we have no leads