brk(2) and stack pointer

[Shaun Jackman]

On 4/28/06, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> Why do you need to care about this?  I suspect if you do care about it,
> you're in for all sorts of games - think about the case where you
> malloc some memory for a stack, and then use clone() to create a new
> thread whose stack is in that malloc'd memory.  That would quite
> probably be below the current brk, so with your code would cause
> brk() to fail.

I agree that there's too many gotchas to check for stack-smashing
reliably. However, I like Jamie Lokier's idea of checking if the stack
point is contained within the new sbrk block. This is almost certainly
an unallowed condition.

> The default stack which the kernel gives you will be contained within
> one "VMA", and the zero'd data segment (edata to brk) will be within
> another - the two of which will not ever be allowed to overlap.  So
> you can consider that this case is dealt with by the kernel.

I was thinking specifically of the uClinux nommu case. I think bFLT
binaries, at least, locate the stack immediately after the bss and
heap.

Cheers,
Shaun