linux-kernel - Re: [PATCH] fs/userfaultfd: Fix maple tree iterator in userfaultfd

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: <CAHk-=wg9WQXBGkNdKD2bqocnN73rDswuWsavBB7T-tekykEn_A@mail.gmail.com>
Date:   Mon, 7 Nov 2022 13:13:43 -0800
From:   Linus Torvalds <torvalds@...uxfoundation.org>
To:     Liam Howlett <liam.howlett@...cle.com>
Cc:     "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "syzbot+0d2014e4da2ccced5b41@...kaller.appspotmail.com" 
        <syzbot+0d2014e4da2ccced5b41@...kaller.appspotmail.com>
Subject: Re: [PATCH] fs/userfaultfd: Fix maple tree iterator in userfaultfd_unregister()

On Mon, Nov 7, 2022 at 12:12 PM Liam Howlett <liam.howlett@...cle.com> wrote:
>
> When iterating the VMAs, the maple state needs to be invalidated if the
> tree is modified by a split or merge to ensure the maple tree node
> contained in the maple state is still valid.  These invalidations were
> missed, so add them to the paths which alter the tree.

I have applied this as an obvious fix, but I would *really* want to
also see longer-term

 - I'd really like the 'mas' operations to have 'vma' specializations
that get the type safety right

 - that mas_pause() name is horrible, please let's just fix it to
something sensible in this context

 - moving the iterator invalidation into split_vma() and vma_merge()
or at least have some other means of not having these mistakes

>From what I can tell, things like mprotect() and mlock() - end up not
using the iterator at all because of this issue. Instead they seem to
just do

                vma = find_vma(current->mm, prev->vm_end);

despite having actually started out with the whole iterator state.
Except for 'apply_mlockall_flags()' that randomly does end up usign
the iterator (and has that mas_pause() as a result).

So it would make *sense* to have "mlock_fixup()" take a MA_STATE
instead of "vma, &prev" as arguments, but it doesn't.

I dunno. Maybe there's some other reason for this very non-intuitive
mix of "sometimes iterators, sometimes not, and always horrible
naming".

                Linus