we had the same issue in bionic when we removed all our alloca()s, modulo
the fact that ours is a VLA rather than alloca(), but same thing:
https://android.googlesource.com/platform/bionic/+/master/libc/bionic/exec.cpp#61
we argued that it doesn't matter in this case though because we'll touch
all the entries, in order, so there's no possibility of jumping off the end
of the stack onto another VMA.
(we have used mmap() instead in more complicated cases though.)
On Thu, Sep 16, 2021 at 1:39 PM Theo de Raadt <dera...@openbsd.org> wrote:
> Alejandro Colomar (man-pages) <alx.manpa...@gmail.com> wrote:
>
> > Hi,
> >
> > I don't know if OpenBSD has a different implementation of alloca(3)
> > than Linux. In Linux, alloca(3) (a.k.a. __builtin_alloca()) can't
> > return NULL, as it can't detect errors.
>
> There are no alloca can return NULL.
>
> > The only way to detect an
> > error is to add a handler for SIGSEGV, AFAIK.
>
> Actually, it is worse than that. Massive alloca have been encountered
> which reach off the stack. For over 20 years we've been on a mission
> to delete alloca in our tree, and these are the last ones that remain,
> because other allocators are very difficult to use in this place.
>
> Maybe we should investigate using mmap. Of the 4 cases, 3 are not
> too difficult, but the 4th case will be very messy, including unwind
> for the 3rd case.
>
> > I found the following code in <lib/libc/gen/exec.c>:
> >
> > argv = alloca((n + 1) * sizeof(*argv));
> > if (argv == NULL) {
> > errno = ENOMEM;
> > return (-1);
> > }
> >
> > But of course, that NULL should never happen, right?
>
> > As a side note, I think you could encapsulate the code calling
> > alloca(3) into a helper macro, to avoid repetition.
>
> I don't see how that would help anything.
>
> > I can prepare a patch if you confirm the bug.
>
> What do you propose to do in your patch?
>
>
>
