[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h6vxfk7l.fsf@hope.eyrie.org>
Date: Tue, 07 Feb 2023 09:39:58 -0800
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: SEGV in `alloca(BIG)` and `long pl[BIG]`
Georgi Guninski <gguninski@...il.com> 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
vital.
> 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
unlikely).
--
Russ Allbery (eagle@...ie.org) <https://www.eyrie.org/~eagle/>
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.
