linux-kernel - Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

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: <20170624150033.GA19381@kroah.com>
Date:   Sat, 24 Jun 2017 17:00:33 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Michal Hocko <mhocko@...e.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Willy Tarreau <w@....eu>
Subject: Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

On Tue, Jun 20, 2017 at 10:41:01PM -0700, Hugh Dickins wrote:
> On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Hugh Dickins <hughd@...gle.com>
> > 
> > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
> 
> The 4.11 and 4.9 patches are fine, but I noticed a couple of corrections
> to this 4.4 one.  There are very unlikely circumstances (on VM_GROWSUP
> architectures only) in which that "highest_vm_end = end" line would be
> wrong: several different ways to fix it, I'm tending to go with Andrea's
> observation that the only need for update has already been done above,
> so just VM_WARN_ON if it's unexpected.
> 
> Hugh
> 
> diff -purN 404n/include/linux/mm.h 404h/include/linux/mm.h
> --- 404n/include/linux/mm.h	2017-06-20 16:48:17.162770068 -0700
> +++ 404h/include/linux/mm.h	2017-06-20 17:36:35.871975695 -0700
> @@ -1283,6 +1283,8 @@ static inline bool vma_is_anonymous(stru
>  	return !vma->vm_ops;
>  }
>  
> +int vma_is_stack_for_task(struct vm_area_struct *vma, struct task_struct *t);
> +
>  extern unsigned long move_page_tables(struct vm_area_struct *vma,
>  		unsigned long old_addr, struct vm_area_struct *new_vma,
>  		unsigned long new_addr, unsigned long len,
> diff -purN 404n/mm/mmap.c 404h/mm/mmap.c
> --- 404n/mm/mmap.c	2017-06-20 16:48:17.166770032 -0700
> +++ 404h/mm/mmap.c	2017-06-20 17:42:31.312682716 -0700
> @@ -923,7 +923,7 @@ again:			remove_next = 1 + (end > next->
>  		else if (next)
>  			vma_gap_update(next);
>  		else
> -			mm->highest_vm_end = end;
> +			VM_WARN_ON(mm->highest_vm_end != vm_end_gap(vma));
>  	}
>  	if (insert && file)
>  		uprobe_mmap(insert);

Thank you, the first chunk was already in my updated tree, and I have
now added the second chunk and will run it through the 0-day tests to
see how it goes...

greg k-h