Probe emission in fstack-clash-protection

Varun Kumar E varunkumare99@gmail.com
Wed May 3 04:36:49 GMT 2023


Hello,

https://godbolt.org/z/P3M8s8jqh
The above case shows that gcc first decreases the stack pointer and then
probes.

As mentioned by Jeff Law (reference
<https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>)
under "More issues with -fstack-check". If an asynchronous signal is
received between the decrement of stack pointer and probing of the pages.
*"In that case, the stack pointer could be pointing beyond the guard into
the heap. The signal arrives and the kernel transfers control to the
registered signal handler. That signal handler is then running while its
stack is pointing into the heap. Thus, the attacker has clashed the stack
and heap, and there's a reasonable chance they can gain control over the
program" *

So, Shouldn't we first probe and if successful only then update the stack
pointer? Or Maybe I have understood it incorrectly.

regards,
Varun


More information about the Gcc mailing list