This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca vs malloc
- From: Jeff Law <law at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Rich Felker <dalias at libc dot org>, Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 19 May 2014 09:41:44 -0600
- Subject: Re: alloca vs malloc
- Authentication-results: sourceware.org; auth=none
- References: <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge> <53768528 dot 1020502 at redhat dot com> <20140516232039 dot GA18631 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1405162355230 dot 24114 at digraph dot polyomino dot org dot uk> <20140519042831 dot GD13048 at spoyarek dot pnq dot redhat dot com> <20140519091525 dot GA17530 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1405191505390 dot 25418 at digraph dot polyomino dot org dot uk>
On 05/19/14 09:30, Joseph S. Myers wrote:
There are various cases where replacing alloca with malloc is not safe
(but use of alloca isn't safe either unless the size allocated is
bounded):
Yup. I hadn't pondered any of these scenarios. At least some of them
probably ought to be discussed with the appropriate POSIX/ISO standards
group.
* If the function's interface does not provide a way for it to return an
error indication for memory allocation failures at all, or people
otherwise reasonably expect it never to fail for that reason, then bounded
alloca / VLAs can be used, but malloc cannot.
These are the cases I'm referring to thought ought to be discussed with
the standards committee.
(I don't know about practical exploitability or CVE-worthiness of that
bug; I just presume that any unbounded stack allocation should be
considered bad, although those where the space allocated is proportional
to the space already used by function arguments passed to the glibc
function are maybe less critical.)
Right. I don't think anyone has done any kind of exploitability
analysis for that particular bug (16962). However, my experience has
been that if there's an unbound alloca, then exploitability is just an
exercise left for the reader :-) So, I'd agree that any unbound stack
allocation should be considered bad.
Jeff