• Andrea Arcangeli's avatar
    coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping · 04f5866e
    Andrea Arcangeli authored
    The core dumping code has always run without holding the mmap_sem for
    writing, despite that is the only way to ensure that the entire vma
    layout will not change from under it.  Only using some signal
    serialization on the processes belonging to the mm is not nearly enough.
    This was pointed out earlier.  For example in Hugh's post from Jul 2017:
    
      https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
    
      "Not strictly relevant here, but a related note: I was very surprised
       to discover, only quite recently, how handle_mm_fault() may be called
       without down_read(mmap_sem) - when core dumping. That seems a
       misguided optimization to me, which would also be nice to correct"
    
    In particular because the growsdown and growsup can move the
    vm_start/vm_end the various loops the core dump does around the vma will
    not be consistent if page faults can happen concurrently.
    
    Pretty much all users calling mmget_not_zero()/get_task_mm() and then
    taking the mmap_sem had the potential to introduce unexpected side
    effects in the core dumping code.
    
    Adding mmap_sem for writing around the ->core_dump invocation is a
    viable long term fix, but it requires removing all copy user and page
    faults and to replace them with get_dump_page() for all binary formats
    which is not suitable as a short term fix.
    
    For the time being this solution manually covers the places that can
    confuse the core dump either by altering the vma layout or the vma flags
    while it runs.  Once ->core_dump runs under mmap_sem for writing the
    function mmget_still_valid() can be dropped.
    
    Allowing mmap_sem protected sections to run in parallel with the
    coredump provides some minor parallelism advantage to the swapoff code
    (which seems to be safe enough by never mangling any vma field and can
    keep doing swapins in parallel to the core dumping) and to some other
    corner case.
    
    In order to facilitate the backporting I added "Fixes: 86039bd3"
    however the side effect of this same race condition in /proc/pid/mem
    should be reproducible since before 2.6.12-rc2 so I couldn't add any
    other "Fixes:" because there's no hash beyond the git genesis commit.
    
    Because find_extend_vma() is the only location outside of the process
    context that could modify the "mm" structures under mmap_sem for
    reading, by adding the mmget_still_valid() check to it, all other cases
    that take the mmap_sem for reading don't need the new check after
    mmget_not_zero()/get_task_mm().  The expand_stack() in page fault
    context also doesn't need the new check, because all tasks under core
    dumping are frozen.
    
    Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
    Fixes: 86039bd3 ("userfaultfd: add new syscall to provide memory externalization")
    Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
    Reported-by: default avatarJann Horn <jannh@google.com>
    Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
    Acked-by: default avatarPeter Xu <peterx@redhat.com>
    Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
    Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
    Reviewed-by: default avatarJann Horn <jannh@google.com>
    Acked-by: default avatarJason Gunthorpe <jgg@mellanox.com>
    Acked-by: default avatarMichal Hocko <mhocko@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    04f5866e
task_mmu.c 44.5 KB