[PATCH] Don't bind to registered ports in bindresvport

[Jeff Law]

On 06/06/2012 06:49 PM, Carlos O'Donell wrote:
> The use of alloca vs. malloc must be evaluated on a case-by-case basis. There are many things to consider when looking at using alloca or malloc.
>
>   * Is this a hot path with a small allocation? If it is then it is very likely a good candidate for using alloca, using malloc would slow down the fast path too much.
>
>   * What is stored in the alloca'd space? Is there a security issue inherent in placing this information at a known offset from the stack pointer? If there is then it might call for using malloc.
>
>   * Is the allocated space large? The use of alloca in glibc is limited and large allocations will need to be taken from malloc.
>
>   * Does the API allow returning ENOMEM? The use of malloc introduces the possibility that the allocation might fail. If the API doesn't allow ENOMEM to be returned then it might be better to use alloca unless there are other circumstances.
>
> At present there is no magic bullet of special procedure for selecting alloca vs. malloc, if there was then we could encode it into this wiki or into a macro.
> ~~~
>
> What else do we need?
If the size of the allocation is known, then it is a good candidate for 
alloca.

If there is a path by which the allocated space is grown, then it needs 
alloca accounting and should conditionally switch to malloc when the 
amount of alloca'd space grows too large.

If the size of the allocation is not known apriori, then serious 
consideration should be given to using malloc or at least have a path 
which falls back to malloc.  This is especially true if the amount of 
allocated space is directly or indirectly under user control.  ie, a 
format string, buffer for reading files, buffer for network data, etc.

There's been *far* too many cases where an attacker can blow out the 
stack resulting in either a DoS attack or via stack shifting open up an 
arbitrary write into another thread's stack or the heap.

Jeff