* Varun Kumar E. via Gcc: > 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.
Let me rephrase a bit. The caller has asserted that (%rsp) is valid upon entry to the function because that's where the return address is stored. That means that (%rsp - 4096) is still in the guard page, so the subsequent probe works. But the kernel fault handler will not write to that location because it has to protect the return address and the red zone, so the first location used is (%rsp - 4096 - 8 - 128) or thereabouts. Jeff, this looks like a real bug to me. It doesn't affect the main thread on GNU/Linux because the kernel uses more than one page for the guard area. However, glibc uses exactly one page. We could change that to two pages on x86-64 at least without ill effects, I believe. Or fix GCC's probing to account for the red zone. Thanks, Florian
