Systemd (PID1) crash with specially crafted D-Bus message

That typically doesn’t go well for long. The moment you write to that local variable (which technically need not happen, but if you don’t write to it, why have the variable at all?), you overwrite data in the heap and/or heap data structures. That will become a problem when the program reads that data or when the memory allocator walks the heap.

Debugging this kind of problem is hard, as the buggy code often will run fine. It ‘just’ triggers problems at some unspecified later time, likely in a completely unrelated part of the program.

So, guard pages ‘below’ the stack were added. They trigger exceptions that kill the offending program when it tries to write to or read from those pages. That doesn’t fully prevent this problem; large stack objects may jump over the protected area (especially in 32-bit code, you don’t want to give up lots of virtual address space to such guard pages, and the amount of address space ‘lost’ can add up fast in multi-threaded programs)

Another way to detect this is to periodically (say in an interrupt handler, or whenever a call to the memory allocator is made) check that the stack pointer has a valid value. That isn’t sure-fire, either. Firstly, it can only detect problems after the fact and secondly, it may not see short violations of the rules.