From: Greg Ungerer <gregungerer@westnet.com.au>
To: Rich Felker <dalias@libc.org>
Cc: linux-embedded@vger.kernel.org,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Matt Mackall <mpm@selenic.com>,
David Woodhouse <dwmw2@infradead.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
Date: Tue, 15 Sep 2015 12:13:34 +1000 [thread overview]
Message-ID: <55F77ECE.3080507@westnet.com.au> (raw)
In-Reply-To: <20150914151717.GF17773@brightrain.aerifal.cx>
Hi Rich,
On 15/09/15 01:17, Rich Felker wrote:
> On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote:
>> On 26/08/15 11:26, Greg Ungerer wrote:
>>> On 21/08/15 05:11, Rich Felker wrote:
>>>> From: Rich Felker <dalias@libc.org>
>>>>
>>>> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
>>>> overlap with all but the last PAGE_SIZE bytes of the stack. This leads
>>>> to catastrophic memory reuse/corruption if brk is used. Fix by setting
>>>> the brk area to zero size to disable its use.
>>>>
>>>> Signed-off-by: Rich Felker <dalias@libc.org>
>>>
>>> It would make sense to run this by David Howells <dhowells@redhat.com>,
>>> I think he wrote this code (added to CC list).
>>>
>>> I have no problem with it, so:
>>>
>>> Acked-by: Greg Ungerer <gerg@uclinux.org>
>>
>> Has anybody picked this up to push to Linus?
>> If not I can take it via the m68knommu tree.
>
> As far as I know, no. If you can do it that would be great.
Patch applied to m68knommu git tree (for-next branch).
(https://git.kernel.org/cgit/linux/kernel/git/gerg/m68knommu.git/)
Regards
Greg
>>>> ---
>>>>
>>>> There is no reason for the kernel to be providing a brk area at all on
>>>> NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
>>>> NOMMU targets, and musl libc goes out of its way to avoid using brk
>>>> that might run into the stack.
>>>
>>> I recall a long time back someone was playing with the idea of setting
>>> the brk to the unused parts of the last data area page. (Somewhat like
>>> this code seems to be trying). That scheme still allocated the full
>>> requested stack size (IIRC) though. And that would have been on bFLT
>>> executables. Anyway, just some historical reference, not really
>>> relevant now.
>>>
>>> Regards
>>> Greg
>>>
>>>
>>>
>>>> --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
>>>> +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
>>>> @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
>>>> PAGE_ALIGN(current->mm->start_brk);
>>>>
>>>> #else
>>>> - /* create a stack and brk area big enough for everyone
>>>> - * - the brk heap starts at the bottom and works up
>>>> - * - the stack starts at the top and works down
>>>> - */
>>>> + /* create a stack area and zero-size brk area */
>>>> stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
>>>> if (stack_size < PAGE_SIZE * 2)
>>>> stack_size = PAGE_SIZE * 2;
>>>> @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
>>>>
>>>> current->mm->brk = current->mm->start_brk;
>>>> current->mm->context.end_brk = current->mm->start_brk;
>>>> - current->mm->context.end_brk +=
>>>> - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
>>>> current->mm->start_stack = current->mm->start_brk + stack_size;
>>>> #endif
>>>>
>>>>
>>>
>
next prev parent reply other threads:[~2015-09-15 2:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 19:11 [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU Rich Felker
2015-08-26 1:26 ` Greg Ungerer
2015-08-26 2:16 ` Rich Felker
2015-09-14 12:13 ` Greg Ungerer
2015-09-14 15:17 ` Rich Felker
2015-09-15 2:13 ` Greg Ungerer [this message]
2015-09-10 14:29 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F77ECE.3080507@westnet.com.au \
--to=gregungerer@westnet.com.au \
--cc=dalias@libc.org \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=paul.gortmaker@windriver.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).