Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Feb 2023 09:39:58 -0800
From: Russ Allbery <>
Subject: Re: SEGV in `alloca(BIG)` and `long pl[BIG]`

Georgi Guninski <> writes:

> Inline are two C warez, which crash on
> `alloca(BIG)` and `long pl[BIG]`.

I believe this is the documented behavior of alloca().  The Linux man
pages, for instance, say:

       The alloca() function returns a pointer to the beginning of the
       allocated space.  If the allocation causes stack overflow, program
       behavior is undefined.

and also:

       Due to the nature of the stack, it is impossible to check if the
       allocation would overflow the space available, and, hence, neither
       is indicating an error.  (However, the program is likely to receive
       a SIGSEGV signal if it attempts to access unavailable space.)

alloca() is rather dangerous to use because it doesn't know in advance how
much space is available on the stack, which is why most documentation of
it recommend against using it except in very special situations where the
size of the allocation is known and the speed benefits of alloca() are

> I think alloca(BIG) should return error if BIG>max_signed_size_t.
> In C++ `new[BUG]` throws exception and core dumps.

Code that does use alloca() generally assumes that it cannot fail and
return NULL, so introducing error return values would cause a whole new
class of bugs.

The real solution is to not use alloca() unless you know exactly what
you're doing and the properties of alloca() are important (which is

Russ Allbery (             <>

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.