Probe emission in fstack-clash-protection

Jeff Law
Wed May 3 05:46:58 GMT 2023

On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
> Hello,
> The above case shows that gcc first decreases the stack pointer and then
> probes.
> As mentioned by Jeff Law (reference
> <>)
> 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.


More information about the Gcc mailing list