This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: alloca and reliable stack-overflow detection in glibc functions
- From: Paul Eggert <eggert at CS dot UCLA dot EDU>
- To: libc-alpha at sources dot redhat dot com
- Date: 04 Feb 2004 00:20:21 -0800
- Subject: Re: alloca and reliable stack-overflow detection in glibc functions
- References: <200402032026.i13KQNrw024574@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> writes:
> glibc does not support arbitrarily small stack sizes.
OK, but I'm not worried about that. I'm worried about small
stack-barrier sizes.
Here's another way to put it. Currently, as I understand it,
setenv() with large arguments can do one of the following:
1. Succeed.
2. Return -1 (due to heap exhaustion).
3. Generate a signal (due to caught stack overflow).
4. Silently corrupt storage (due to uncaught stack overflow
after a large alloca()).
I don't want (4) to happen, as it's real nasty (e.g., security holes).
Can I rule out (4) within glibc by arranging for the stack to have at
least __MAX_ALLOCA_CUTOFF bytes of inaccessible stack-barrier address
space just past the allocated stack end? I had thought that was the
partly the goal of __MAX_ALLOCA_CUTOFF, but perhaps I'm wrong.
If not, is there some other way to rule out (4) within glibc?