kernel/fork: only call untrack_pfn_clear() on VMAs duplicated for fork()

commit e9f180d
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Apr 22 16:49:42 2025 +0200

    kernel/fork: only call untrack_pfn_clear() on VMAs duplicated for fork()

    Not intuitive, but vm_area_dup() located in kernel/fork.c is not only used
    for duplicating VMAs during fork(), but also for duplicating VMAs when
    splitting VMAs or when mremap()'ing them.

    VM_PFNMAP mappings can at least get ordinarily mremap()'ed (no change in
    size) and apparently also shrunk during mremap(), which implies
    duplicating the VMA in __split_vma() first.

    In case of ordinary mremap() (no change in size), we first duplicate the
    VMA in copy_vma_and_data()->copy_vma() to then call untrack_pfn_clear() on
    the old VMA: we effectively move the VM_PAT reservation.  So the
    untrack_pfn_clear() call on the new VMA duplicating is wrong in that
    context.

    Splitting of VMAs seems problematic, because we don't duplicate/adjust the
    reservation when splitting the VMA.  Instead, in memtype_erase() -- called
    during zapping/munmap -- we shrink a reservation in case only the end
    address matches: Assume we split a VMA into A and B, both would share a
    reservation until B is unmapped.

    So when unmapping B, the reservation would be updated to cover only A.
    When unmapping A, we would properly remove the now-shrunk reservation.
    That scenario describes the mremap() shrinking (old_size > new_size),
    where we split + unmap B, and the untrack_pfn_clear() on the new VMA when
    is wrong.

    What if we manage to split a VM_PFNMAP VMA into A and B and unmap A first?
    It would be broken because we would never free the reservation.  Likely,
    there are ways to trigger such a VMA split outside of mremap().

    Affecting other VMA duplication was not intended, vm_area_dup() being used
    outside of kernel/fork.c was an oversight.  So let's fix that for; how to
    handle VMA splits better should be investigated separately.

    With a simple reproducer that uses mprotect() to split such a VMA I can
    trigger

    x86/PAT: pat_mremap:26448 freeing invalid memtype [mem 0x00000000-0x00000fff]

    Link: https://lkml.kernel.org/r/20250422144942.2871395-1-david@redhat.com
    Fixes: dc84bc2 ("x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

JIRA: https://issues.redhat.com/browse/RHEL-77742
Signed-off-by: Nico Pache <npache@redhat.com>

Author: PacheNico

kernel/fork.c

@@ -504,10 +504,6 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig)
 	vma_numab_state_init(new);
 	dup_anon_vma_name(orig, new);
 
-	/* track_pfn_copy() will later take care of copying internal state. */
-	if (unlikely(new->vm_flags & VM_PFNMAP))
-		untrack_pfn_clear(new);
-
 	return new;
 }
 
@@ -695,6 +691,11 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
 		tmp = vm_area_dup(mpnt);
 		if (!tmp)
 			goto fail_nomem;
+
+		/* track_pfn_copy() will later take care of copying internal state. */
+		if (unlikely(tmp->vm_flags & VM_PFNMAP))
+			untrack_pfn_clear(tmp);
+
 		retval = vma_dup_policy(mpnt, tmp);
 		if (retval)
 			goto fail_nomem_policy;