This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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]

alloca and reliable stack-overflow detection in glibc functions


Currently many GNU apps can invoke alloca (N) for large N.  This has
undefined behavior, which means these apps can trash their memory
without warning.  Some of the problems occur in gnulib code, which is
adapted from glibc, so I thought I'd ask about the "right" way to fix
this so that any gnulib fixes in this area can be eventually merged
back into glibc.

First, glibc's __libc_use_alloca seems to be designed for this
problem, but it is not used uniformly in glibc.  For example, it's not
used by sysdeps/generic/setenv.c, even though setenv uses alloca (N)
for arbitrarily-large values of N.  Can I assume that this sort of
problem is inadvertent, and that functions like setenv should be
modified to use __libc_use_alloca?

Second, __MAX_ALLOCA_CUTOFF is 64 * 1024, so __libc_use_alloca
currently allows alloca (N) if N is less than 64 KiB.  Howerver, my
understanding from Bruno Haible is that in some versions of Linux one
can use /proc/sys/vm/heap-stack-gap to set the gap between the stack
and heap to values as small as 4 KiB, which suggests that
__MAX_ALLOCA_CUTOFF should be 4 KiB.  Am I misunderstanding the intent
of __MAX_ALLOCA_CUTOFF?  (For all I know /proc/sys/vm/heap-stack-gap
can be set to zero, in which case no gap would suffice.)

Bruno supplied a small program that illustrates some of the issues here:

#include <stdio.h>
#include <stdlib.h>
int main (void) { alloca(0x7fead000); printf("Hello world\n"); }

This segfaults on my box (Debian GNU/Linux 3.0r1 x86, Linux
2.4.18-bf2.4, glibc 2.2.5-11.5).


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