This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: brk(2) and stack pointer


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]