On Thu, 2016-09-15 at 19:41 +0200, Andrea Arcangeli wrote: > The rmap_walk can access vm_page_prot (and potentially vm_flags in > the > pte/pmd manipulations). So it's not safe to wait the caller to update > the vm_page_prot/vm_flags after vma_merge returned potentially > removing the "next" vma and extending the "current" vma over the > next->vm_start,vm_end range, but still with the "current" vma > vm_page_prot, after releasing the rmap locks. > > The vm_page_prot/vm_flags must be transferred from the "next" vma to > the current vma while vma_merge still holds the rmap locks. > > The side effect of this race condition is pte corruption during > migrate as remove_migration_ptes when run on a address of the "next" > vma that got removed, used the vm_page_prot of the current vma. > > migrate mprotect > ------------ ------------- > migrating in "next" vma > vma_merge() # removes "next" vma and > # extends "current" vma > # current vma is not with > # vm_page_prot updated > remove_migration_ptes > read vm_page_prot of current "vma" > establish pte with wrong permissions > vm_set_page_prot(vma) # too late! > change_protection in the old vma range > only, next range is not updated > > This caused segmentation faults and potentially memory corruption in > heavy mprotect loads with some light page migration caused by > compaction in the background. > > Reported-by: Aditya Mandaleeka <adityam@xxxxxxxxxxxxx> > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> Reviewed-by: Rik van Riel <riel@xxxxxxxxxx> Tested-by: Rik van Riel <riel@xxxxxxxxxx> -- All rights reversed
Attachment:
signature.asc
Description: This is a digitally signed message part