linux-kernel - Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Sep 2015 22:13:03 +1000
From:	Greg Ungerer <gregungerer@...tnet.com.au>
To:	Rich Felker <dalias@...c.org>, linux-embedded@...r.kernel.org
Cc:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Matt Mackall <mpm@...enic.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on
 NOMMU

Hi Rich,


On 26/08/15 11:26, Greg Ungerer wrote:
> On 21/08/15 05:11, Rich Felker wrote:
>> From: Rich Felker <dalias@...c.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@...c.org>
>
> It would make sense to run this by David Howells <dhowells@...hat.com>,
> I think he wrote this code (added to CC list).
>
> I have no problem with it, so:
>
> Acked-by: Greg Ungerer <gerg@...inux.org>

Has anybody picked this up to push to Linus?
If not I can take it via the m68knommu tree.

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
>>
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/