linux-kernel - Re: [PATCH] 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: <20170705063645.GA10354@dhcp22.suse.cz>
Date:   Wed, 5 Jul 2017 08:36:46 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ben Hutchings <ben@...adent.org.uk>, Willy Tarreau <w@....eu>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        linux-distros@...openwall.org,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas

On Tue 04-07-17 16:31:52, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings <ben@...adent.org.uk> wrote:
> >
> > We have:
> >
> > bottom = 0xff803fff
> > sp =     0xffffb178
> >
> > The relevant mappings are:
> >
> > ff7fc000-ff7fd000 rwxp 00000000 00:00 0
> > fffdd000-ffffe000 rw-p 00000000 00:00 0                                  [stack]
> 
> Ugh. So that stack is actually 8MB in size, but the alloca() is about
> to use up almost all of it, and there's only about 28kB left between
> "bottom" and that 'rwx' mapping.
> 
> Still, that rwx mapping is interesting: it is a single page, and it
> really is almost exactly 8MB below the stack.
> 
> In fact, the top of stack (at 0xffffe000) is *exactly* 8MB+4kB from
> the top of that odd one-page allocation (0xff7fd000).

Very interesting! I would be really curious whether changing ulimit to
something bigger changes the picture. And if this is really the case
what we are going to do here. We can special case a single page mapping
under the stack but that sounds quite dangerous for something that is
dubious in itself. PROT_NONE would explicitly fault but we would simply
run over this mapping too easily and who knows what might end up below
it. So to me the guard gap does its job here.

Do you want me to post the earier patch to ignore PROT_NONE mapping
or we should rather wait for this one to get more details?
-- 
Michal Hocko
SUSE Labs