Probe emission in fstack-clash-protection

Jeff Law jeffreyalaw@gmail.com
Wed May 3 05:46:58 GMT 2023



On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
> 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.

That may ultimately be better for -fstack-check to make it more robust, 
but it still wouldn't be a viable alternative for stack clash protection 
for the reasons laid out in that blog post.

jeff


More information about the Gcc mailing list