mm: lock newly mapped VMA which can be modified after it becomes visible

JIRA: https://issues.redhat.com/browse/RHEL-48221

This patch is a backport of the following upstream commit:
commit 33313a7
Author: Suren Baghdasaryan <surenb@google.com>
Date:   Sat Jul 8 12:12:11 2023 -0700

    mm: lock newly mapped VMA which can be modified after it becomes visible

    mmap_region adds a newly created VMA into VMA tree and might modify it
    afterwards before dropping the mmap_lock.  This poses a problem for page
    faults handled under per-VMA locks because they don't take the mmap_lock
    and can stumble on this VMA while it's still being modified.  Currently
    this does not pose a problem since post-addition modifications are done
    only for file-backed VMAs, which are not handled under per-VMA lock.
    However, once support for handling file-backed page faults with per-VMA
    locks is added, this will become a race.

    Fix this by write-locking the VMA before inserting it into the VMA tree.
    Other places where a new VMA is added into VMA tree do not modify it
    after the insertion, so do not need the same locking.

    Cc: stable@vger.kernel.org
    Signed-off-by: Suren Baghdasaryan <surenb@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Rafael Aquini <aquini@redhat.com>

Author: aquini

mm/mmap.c

@@ -2774,6 +2774,8 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 	if (vma->vm_file)
 		i_mmap_lock_write(vma->vm_file->f_mapping);
 
+	/* Lock the VMA since it is modified after insertion into VMA tree */
+	vma_start_write(vma);
 	vma_iter_store(&vmi, vma);
 	mm->map_count++;
 	if (vma->vm_file) {