lkml.org 
[lkml]   [2017]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: KASAN: use-after-free Read in __do_page_fault
On Tue, Oct 31, 2017 at 6:57 AM, Vlastimil Babka <vbabka@suse.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

\
 
 \ /
  Last update: 2017-10-31 16:38    [W:0.794 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site