linux-kernel - Re: [PATCH v2] x86: increase MIN_GAP to include randomized stack

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]

Message-ID: <20090907082815.GA12212@tiehlicka.suse.cz>
Date:	Mon, 7 Sep 2009 10:28:15 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Ingo Molnar <mingo@...hat.com>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	"H . Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2] x86: increase MIN_GAP to include randomized stack

On Fri 04-09-09 11:37:00, Michal Hocko wrote:
> Currently we are not including randomized stack size when calculating
> mmap_base address in arch_pick_mmap_layout for topdown case. This might
> cause that mmap_base starts in the stack reserved area because stack is
> randomized by 1GB for 64b (8MB for 32b) and the minimum gap is 128MB.

Just for reference, attached you can find simple reproduction program
(which has been attached to our original bug report which unfortunately I
cannot make public). 

It prints memory layout when maximum mmaped address is too close to the
stack top. I understand that stack_top (as read from /proc/<PID>/stat)
is not the best choice because it doesn't include auxv, env and argv but
this should not influence the real problem detection here.

Reproduction steps:
cc -o manymap manymap.c
ulimit -v unlimited
while true
do
	./manymap || break
done

> 
> If the stack really grows down to mmap_base then we can get silent mmap
> region overwrite by the stack values.
> 
> Let's include maximum stack randomization size into MIN_GAP which is
> used as the low bound for the gap in mmap.
> 
> Signed-off-by: Michal Hocko <mhocko@...e.cz>
> ---
>  arch/x86/mm/mmap.c |   21 +++++++++++++++++++--
>  1 files changed, 19 insertions(+), 2 deletions(-)
> 
> I wasn't sure about STACK_RND_MASK because it is defined also in 
> arch/x86/include/asm/elf.h and I couldn't find a common header file for 
> both of them. If you have any idea I would like to help with that.
> Or should we just let it for later cleanup?
> 
> I think that this is also stable material and I will repost it to 
> stable@...nel.org once you ack it.
> 
> Changes from v1:
> Fixed unsigned int overflow in MIN_GAP calculation.
> 
> 
> diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
> index 1658296..ac41955 100644
> --- a/arch/x86/mm/mmap.c
> +++ b/arch/x86/mm/mmap.c
> @@ -30,12 +30,29 @@
>  #include <linux/limits.h>
>  #include <linux/sched.h>
>  
> +/* 1GB for 64bit, 8MB for 32bit definition taken from arch/x86/include/asm/elf.h */
> +#ifndef STACK_RND_MASK
> +#define STACK_RND_MASK (test_thread_flag(TIF_IA32) ? 0x7ff : 0x3fffff)
> +#endif
> +
> +static unsigned int stack_maxrandom_size(void)
> +{
> +	unsigned int max = 0;
> +	if ((current->flags & PF_RANDOMIZE) &&
> +		!(current->personality & ADDR_NO_RANDOMIZE)) {
> +		max = ((-1U) & STACK_RND_MASK) << PAGE_SHIFT;
> +	}
> +
> +	return max;
> +}
> +
> +
>  /*
>   * Top of mmap area (just below the process stack).
>   *
> - * Leave an at least ~128 MB hole.
> + * Leave an at least ~128 MB hole with possible stack randomization.
>   */
> -#define MIN_GAP (128*1024*1024)
> +#define MIN_GAP (128*1024*1024UL + stack_maxrandom_size())
>  #define MAX_GAP (TASK_SIZE/6*5)
>  
>  /*
> -- 
> 1.6.3.3
> 
> --
> 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/

-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

View attachment "manymap.c" of type "text/x-csrc" (2365 bytes)