linux-kernel - Re: KASAN: use-after-free Read in __do_page

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: <CA+55aFwWJyArZMEuo1-4+VaiP95e__cRHkVvrfiQ+NUVJ15DNQ@mail.gmail.com>
Date:   Tue, 31 Oct 2017 08:37:47 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot 
        <bot+6a5269ce759a7bb12754ed9622076dc93f65a1f6@...kaller.appspotmail.com>,
        Jan Beulich <JBeulich@...e.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Laurent Dufour <ldufour@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        syzkaller-bugs@...glegroups.com,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Hugh Dickins <hughd@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        linux-mm <linux-mm@...ck.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: KASAN: use-after-free Read in __do_page_fault

On Tue, Oct 31, 2017 at 6:57 AM, Vlastimil Babka <vbabka@...e.cz> wrote:
>
> However, __do_page_fault() only expects that mmap_sem to be released
> when handle_mm_fault() returns with VM_FAULT_RETRY. It doesn't expect it
> to be released and then acquired again, because then vma can be indeed
> gone.

Yes. Accessing "vma" after calling "handle_mm_fault()" is a bug. An
unfortunate issue with userfaultfd.

The suggested fix to simply look up pkey beforehand seems sane and simple.

But sadly, from a quick check, it looks like arch/um/ has the same
bug, but even worse. It will do

 (a) handle_mm_fault() in a loop without re-calculating vma. Don't ask me why.

 (b) flush_tlb_page(vma, address); afterwards

but much more importantly, I think __get_user_pages() is broken in two ways:

 - faultin_page() does:

        ret = handle_mm_fault(vma, address, fault_flags);
        ...
        if ((ret & VM_FAULT_WRITE) && !(vma->vm_flags & VM_WRITE))

   (easily fixed the same way)

 - more annoyingly and harder to fix: the retry case in
__get_user_pages(), and the VMA saving there.

Ho humm.

Andrea, looking at that get_user_pages() case, I really think it's
userfaultfd that is broken.

Could we perhaps limit userfaultfd to _only_ do the VM_FAULT_RETRY,
and simply fail for non-retry faults?

             Linus