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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <cover.1767638272.git.lorenzo.stoakes@oracle.com>
Date: Mon,  5 Jan 2026 20:11:46 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato <pfalcato@...e.de>, Yeoreum Yun <yeoreum.yun@....com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        David Hildenbrand <david@...nel.org>,
        Jeongjun Park <aha310510@...il.com>, Rik van Riel <riel@...riel.com>,
        Harry Yoo <harry.yoo@...cle.com>
Subject: [PATCH v2 0/4] mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge

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