[PATCH v2 0/4] mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA
merges") introduced the ability to merge previously unavailable VMA merge
scenarios.

However, it is handling merges incorrectly when it comes to mremap() of a
faulted VMA adjacent to an unfaulted VMA. The issues arise in three cases:

1. Previous VMA unfaulted:

              copied -----|
                          v
	|-----------|.............|
	| unfaulted |(faulted VMA)|
	|-----------|.............|
	     prev

2. Next VMA unfaulted:

              copied -----|
                          v
	            |.............|-----------|
	            |(faulted VMA)| unfaulted |
                    |.............|-----------|
		                      next

3. Both adjacent VMAs unfaulted:

              copied -----|
                          v
	|-----------|.............|-----------|
	| unfaulted |(faulted VMA)| unfaulted |
	|-----------|.............|-----------|
	     prev                      next

This series fixes each of these cases, and introduces self tests to assert
that the issues are corrected.

I also test a further case which was already handled, to assert that my
changes continues to correctly handle it:

4. prev unfaulted, next faulted:

              copied -----|
                          v
	|-----------|.............|-----------|
	| unfaulted |(faulted VMA)|  faulted  |
	|-----------|.............|-----------|
	     prev                      next

This bug was discovered via a syzbot report, linked to in the first patch
in the series, I confirmed that this series fixes the bug.

I also discovered that we are failing to check that the faulted VMA was not
forked when merging a copied VMA in cases 1-3 above, an issue this series
also addresses.

I also added self tests to assert that this is resolved (and confirmed that
the tests failed prior to this).

I also cleaned up vma_expand() as part of this work, renamed
vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was
unduly confusing, and simplified the comments around this function.

v2:
* Provide more general solution that fixes failure raised by Harry (thanks
  very much for raising the issues!)
* Additionally discovered another failure case (prev unfaulted merge with
  faulted). The general solution solves this also.
* Reworked vma_expand() to be more logical and understandable.
* Added vma_merge_copied_range() specifically for mremap() so we abstract
  out the invocation of vma_merge_new_range() to make things a little more
  straightforward.
* Added exhaustive self tests for every case, including unfaulted, faulted,
  faulted (which was previously correctly handled by vma_expand()).
* Discovered that we are incorrectly allowing merges between
  faulted/unfaulted mremap() for forked VMAs, so adjusted
  is_mergeable_anon_vma() to correctly check for this for the mremap()
  case.
* While I was there, renamed vma_had_uncowed_parents() to
  vma_is_fork_child() as the name was confusing, and removed duplicative
  comments.
* Added self tests to assert correctness for the forked VMA changes.

v1:
https://lore.kernel.org/all/20260102205520.986725-1-lorenzo.stoakes@oracle.com/

Lorenzo Stoakes (4):
  mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge
  tools/testing/selftests: add tests for !tgt, src mremap() merges
  mm/vma: enforce VMA fork limit on unfaulted,faulted mremap merge too
  tools/testing/selftests: add forked (un)/faulted VMA merge tests

 mm/vma.c                           | 111 ++++++---
 mm/vma.h                           |   3 +
 tools/testing/selftests/mm/merge.c | 384 +++++++++++++++++++++++++++--
 3 files changed, 434 insertions(+), 64 deletions(-)

--
2.52.0