linux-kernel - Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at

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: <alpine.LSU.2.11.1706212050330.19676@eggly.anvils>
Date:   Wed, 21 Jun 2017 21:23:21 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Oleg Nesterov <oleg@...hat.com>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        kernel test robot <xiaolong.ye@...el.com>,
        Michal Hocko <mhocko@...e.com>,
        LKML <linux-kernel@...r.kernel.org>, LKP <lkp@...org>
Subject: Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c

On Wed, 21 Jun 2017, Oleg Nesterov wrote:
> On 06/21, Linus Torvalds wrote:
> >
> > Hugh, Michal - I also merged Helge's drop-up cleanup, is there
> > anything I've missed? I think Oleg had something, but I can't recall
> > right now, and I might just have missed it.
> 
> Well, I meant, perhaps we need a bit more changes to ensure that a new
> GROWSDOWN vma can't come without a gap below. But this is really minor,
> we can do this later even if I am right.

I'm mortified.  At last I understand you, and see that you spelt it out
perfectly clearly in your "unmapped_gap" mail earlier in another thread,
when I was in a rush to prioritize what bugs needed looking at first,
and brusquely persuaded you to say that this is only a minor defect.

Well, yes, it's not a new vulnerability and it's not a new regression,
and the users of MAP_GROWSDOWN are few and far between, and often the
assignment of holes will work out just fine; but it's an embarrassing
oversight on my part, that everything was geared to inflating the
size of the existing VM_GROWS vmas, completely forgetting to inflate
the size of the area to be added.

Without reading you thoroughly (and all the fault mine not yours),
I had thought you were referring to the way that a MAP_GROWSDOWN
area may be assigned a place in which the stack_guard_gap would
immediately prevent it from growing down afterwards (and I'm not
sure what to do about that).  But your point is that it may be
assigned a place in which there is not even a stack_guard_gap
below it.  (And so the bug that trinity found would not even
depend upon MAP_FIXED.)

I'll go back to read you again and think on the best way to
correct that, I hope it won't need lots of plumbing through
different levels.

Hugh