• D
    mm, oom: fix concurrent munlock and oom reaper unmap, v3 · 27ae357f
    David Rientjes 提交于
    Since exit_mmap() is done without the protection of mm->mmap_sem, it is
    possible for the oom reaper to concurrently operate on an mm until
    MMF_OOM_SKIP is set.
    
    This allows munlock_vma_pages_all() to concurrently run while the oom
    reaper is operating on a vma.  Since munlock_vma_pages_range() depends
    on clearing VM_LOCKED from vm_flags before actually doing the munlock to
    determine if any other vmas are locking the same memory, the check for
    VM_LOCKED in the oom reaper is racy.
    
    This is especially noticeable on architectures such as powerpc where
    clearing a huge pmd requires serialize_against_pte_lookup().  If the pmd
    is zapped by the oom reaper during follow_page_mask() after the check
    for pmd_none() is bypassed, this ends up deferencing a NULL ptl or a
    kernel oops.
    
    Fix this by manually freeing all possible memory from the mm before
    doing the munlock and then setting MMF_OOM_SKIP.  The oom reaper can not
    run on the mm anymore so the munlock is safe to do in exit_mmap().  It
    also matches the logic that the oom reaper currently uses for
    determining when to set MMF_OOM_SKIP itself, so there's no new risk of
    excessive oom killing.
    
    This issue fixes CVE-2018-1000200.
    
    Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1804241526320.238665@chino.kir.corp.google.com
    Fixes: 21292580 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
    Signed-off-by: NDavid Rientjes <rientjes@google.com>
    Suggested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: NMichal Hocko <mhocko@suse.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: <stable@vger.kernel.org>	[4.14+]
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    27ae357f
oom_kill.c 29.7 KB