This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 1/3] posix: Remove dynamic memory allocation from execl{e,p}
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 1 Feb 2016 15:18:36 -0200
- Subject: Re: [PATCH v2 1/3] posix: Remove dynamic memory allocation from execl{e,p}
- Authentication-results: sourceware.org; auth=none
- References: <1454343665-1706-1-git-send-email-adhemerval dot zanella at linaro dot org> <1454343665-1706-2-git-send-email-adhemerval dot zanella at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1602011648030 dot 2674 at digraph dot polyomino dot org dot uk>
On 01-02-2016 14:52, Joseph Myers wrote:
> On Mon, 1 Feb 2016, Adhemerval Zanella wrote:
>
>> + char *argv[argc+1];
>> + va_start (ap, arg);
>> + argv[0] = (char*) arg;
>> + for (i = 1; i < argc; i++)
>> + argv[i] = va_arg (ap, char *);
>> + argv[i] = NULL;
>
> I don't see how you're ensuring this stack allocation is safe (i.e. if
> it's too big, it doesn't corrupt memory that's in use by other threads).
> Can't it jump beyond any guard page and start overwriting other memory,
> possibly in use by another thread, before reaching unmapped memory? I'd
> expect safe large stack allocations (as with -fstack-check) to need to
> touch the pages in the right order (and doing that safely probably means
> using -fstack-check).
>
Right, it is not ensuring the safeness. Is '-fstack-check' the suffice
option to ensure it or do we need a more strict one?