# alloca() problem

- Thread: https://externals.io/message/10441
- Original archive: https://news-web.php.net/php.internals/10441
- Started by Ilia Alshanetsky on 2004-06-14T15:38:30+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #10441 — Ilia Alshanetsky — 2004-06-14T15:38:30+00:00

URL: https://externals.io/message/10441#10441

There is a rather nasty crash possible in PHP due to the usage of the alloca() 
function as can be demonstrated by bug #28064.
Simpler bug replication case:
php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); '

The problem is the result of missing checks to determine if alloca() had 
worked or not. The problem is further compounded by the fact that alloca() is 
a dangerous function that will not always return `NULL` on failure, making the 
return value check unreliable (read alloca manpage excerpt below).
In PHP4 this function is only used about 7 times, while PHP5 uses it a little 
more frequently about 38 times. I think it would be best if do_alloca was 
made to use emalloc that can safely handle allocation failures.
Alloca() is already an emalloc wrapper on Apple, HPUX, Windows, Netware.

Excerpt from alloca manpage:

NOTES ON THE GNU VERSION
       Normally, gcc translates calls to alloca by inlined code. This is not 
done when either the -ansi or the  -fno-builtin  option  is  given.  But  
beware!  By  default  the  glibc  version of <stdlib.h> includes       
<alloca.h> and that contains the line  # define alloca(size)   
__builtin_alloca (size) with messy consequences if one has a private version 
of this function.

       The fact that the code is inlined, means that it is impossible to take 
the address of this function, or to change its behaviour by linking with a 
different library.

       The inlined code often consists of a single instruction adjusting the 
stack pointer, and does not check for stack overflow.  Thus, there is no `NULL` 
error return.

BUGS
       The alloca function is machine and compiler dependent. On many systems 
its implementation is buggy. Its use is discouraged.

       On  many  systems  alloca  cannot  be used inside the list of arguments 
of a function call, because the stack space reserved by alloca would appear 
on the stack in the middle of the space  for the function arguments

Ilia

---

## #10442 — Ard Biesheuvel — 2004-06-14T16:05:51+00:00

URL: https://externals.io/message/10441#10442 · In reply to: #10441

Ilia Alshanetsky wrote:
> There is a rather nasty crash possible in PHP due to the usage of the alloca() 
> function as can be demonstrated by bug #28064.
> Simpler bug replication case:
> php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); '
> 

The following two fragments will lead to virtually identical code:

     void foo()
     {
         char bar[2048];
         ...
     }

and

     void foo()
     {
         char *bar = alloca(2048);
         ....

They both start out by moving the stack pointer down 2k to leave enough 
room for bar, and they will both crash in a similar way if the stack 
doesn't have enough room available.

I think that not alloca() itself but its improper use is the problem 
here. Any function will cause a crash if you call it when your stack is 
full.  Just be sensible about when (not to) use it.

-- 
Ard

---

## #10443 — Ilia Alshanetsky — 2004-06-14T16:10:46+00:00

URL: https://externals.io/message/10441#10443 · In reply to: #10442

Virtually all current uses involve some form of user input, which means that 
the user can exploit the problem. When bar[2048] is used to create a buffer 
of a certain known size that never change, with alloca a buffer of undermined 
size is created in most cases.

The only 'safe' way to use the function would be to put it inside a wrapper 
that would check the size against some preset limit and based on that 
determine if alloca or emalloc should be used. The length would also need to 
be stored to allow the free wrapper to determine if efree() is needed. These 
safety checks may offset the miniscule speed advantage gained by using alloca 
anyway, especially when the length is being calculated inside alloca call.

Ilia

---

## #10445 — Sterling Hughes — 2004-06-14T16:27:09+00:00

URL: https://externals.io/message/10441#10445 · In reply to: #10443

> 
> Virtually all current uses involve some form of user input, which means that
> the user can exploit the problem. When bar[2048] is used to create a buffer
> of a certain known size that never change, with alloca a buffer of undermined
> size is created in most cases.
> 
> The only 'safe' way to use the function would be to put it inside a wrapper
> that would check the size against some preset limit and based on that
> determine if alloca or emalloc should be used. The length would also need to
> be stored to allow the free wrapper to determine if efree() is needed. These
> safety checks may offset the miniscule speed advantage gained by using alloca
> anyway, especially when the length is being calculated inside alloca call.
> 

Calling malloc is generally not that expensive as you would hope that
the operating system would give you reasonable locality in the cases
where i've seen alloca() used.  Doing a stack size check is still
dangerous, simply because you don't know what has been previously
allocated off the stack, nor do you know what will be allocated off
the stack further down within the function.

Calling do_alloca() to avoid a heap access is a bottom drawer
optimization, and yields very little when it comes to improving php's
memory usage patterns (as opposed to a fix block allocator)...  ie, i
agree with ilia - it should just be hosed.

-sterling