Firstly, it's not exactly a novel problem - as the advisory points out, there were earlier public examples of the bug class in 2005 and 2010.

That aside, the issue here is that you can have a program that correctly writes only to properly allocated objects on the heap, and to properly allocated objects on that stack: but if you can get the stack to grow down into the heap without it being detected, now your properly-allocated objects on the heap alias part of the stack (and your properly-allocated objects on the stack alias part of the heap). So now the correct writes done by the program can write to unintended places, like return values on the stack or function pointers in the heap.

The core trick is the "without it being detected" part. What they've done is find places - some of them in library code - that the stack is grown by more than the size of the guard page in one go, and where writing to the guard page itself can be avoided (or in the BSD case, they've found ways that the guard page itself can be disabled). There's also some other clever tricks around expanding the stack and the heap.

> If I control the stack pointer and can write to where it points, I can write to arbitrary in process memory. Sure!

But you don't usually have that sort of control. Normally you'd use something like a buffer overflow on a stack allocated buffer.

This thing is a problem even if you have no buffer overflows on stack and do not have arbitrary write access to anywhere on stack.

What's happening here that the program gets confused about how large its stack is, and keeps utilizing more memory than it should for the stack. But that memory is allocated for heap objects, so a simple write to one of these (not requiring any sort of buffer overflow or other such bug to exploit) could be used to smash the stack.