This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][BZ #16009] Memory handling in strxfrm_l()
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Leonhard Holz <leonhard dot holz at web dot de>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 17:22:05 +0000
- Subject: Re: [RFC][BZ #16009] Memory handling in strxfrm_l()
- Authentication-results: sourceware.org; auth=none
- References: <546DCC25 dot 4020808 at web dot de> <20141121040317 dot GT22465 at brightrain dot aerifal dot cx> <546F12A3 dot 5030204 at web dot de>
On Fri, 21 Nov 2014, Leonhard Holz wrote:
> I took a look at __libc_use_alloca and it's just
>
> extern inline int __libc_use_alloca (size_t size)
> {
> return size <= __MAX_ALLOCA_CUTOFF;
> }
>
> Should'nt it consider the currently used stack size to see if there is enough
> stack memory left? Or do I have a too simple idea of OS stack memory
> handling...
The security requirement is simply that pages up to __MAX_ALLOCA_CUTOFF
(plus non-alloca stack requirements) beyond the current stack pointer must
either be available for the stack, or must be unmapped so that attempted
writes to them result in a fatal signal - that alloca can't overflow from
the stack into other allocated and writable memory regions.
I don't know what guarantees are provided in this regard by the Linux
kernel / glibc's allocation of thread stacks.
--
Joseph S. Myers
joseph@codesourcery.com