From: Lance Yang <lance.yang@linux.dev>
To: david@kernel.org
Cc: muchun.song@linux.dev, osalvador@suse.de,
akpm@linux-foundation.org, rppt@kernel.org, peterx@redhat.com,
linmiaohe@huawei.com, lokeshgidra@google.com, liam@infradead.org,
kylebot@openai.com, ljs@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mm/userfaultfd: only allocate anon_vma in CoW mappings
Date: Thu, 15 Oct 2026 16:16:25 +0800 [thread overview]
Message-ID: <20261015081625.4974-1-lance.yang@linux.dev> (raw)
In-Reply-To: <20261014-copy_hugetlb_page_range-v1-1-5b68e03fe7fe@kernel.org>
On Wed, Oct 14, 2026 at 01:53:11PM +0200, David Hildenbrand (Arm) wrote:
>find_vma_and_prepare_anon() can end up allocating an anon_vma in VMAs that
>are not CoW mappings, which is wrong.
>
>If we have a MAP_SHARED R/O file mapped, we lack VM_SHARED (but do have
>VM_MAYSHARE) and lack VM_MAYWRITE.
>
>While uffd later rejects such mappings (uffd registration requires
>VM_MAYWRITE, see comment in validate_dst_vma) find_vma_and_prepare_anon()
>still wrongly allocates an anon vma before it validates the vma.
>
>This in turn later confuses copy_page_range()->vma_needs_copy() such
>that we end up calling copy_hugetlb_page_range() with ranges that
>actually do not contain *any* per-pagetable information that would
>require copying, which is the basis for PMD-table sharing in the first
>place.
>
>copy_hugetlb_page_range() should not have to worry about shared
>PMD tables at all: it doesn't make any sense to copy page tables that are
>shared, as they can be fully recreated later. Ending up in the function
>with shareable page tables is the real issue.
>
>If a destination PMD table is shared in copy_hugetlb_page_range(), it
>might get concurrently unshared as we are not holding relevant
>locks, resulting in us using a page table that is no longer mapped and
>possibly freed after calling:
>
> dst_pte = huge_pte_alloc(dst, dst_vma, addr, sz);
>
>To fix it, do not allocate an anon_vma in non-CoW mappings and add a
>safety guard to copy_hugetlb_page_range(), making sure that we never
>end up messing with shared PMD tables in there.
>
>Before commit 867a43a34ff8a ("userfaultfd: use per-vma locks in userfaultfd
>operations") we would always validate the VMA before allocating an
>anon_vma, and consequently never wrongly allocate an anon_vma.
>
>As uffd_lock_vma() is part of the same lookup machinery and
>also contains a misleading VM_SHARED check, change that one as well
>directly for consistency.
>
>A follow-up cleanup will stop taking the hugetlb_vma_lock_read(src_vma)
>lock in copy_hugetlb_page_range() entirely. Further, the usage of
>VM_SHARED in userfaultfd code should be cleaned up later to focus on
>CoW vs. non-CoW mappings.
>
>Reported-by: Kyle Zeng <kylebot@openai.com>
>Fixes: 867a43a34ff8a ("userfaultfd: use per-vma locks in userfaultfd operations")
>Cc: stable@vger.kernel.org
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---
Tested-by: Lance Yang <lance.yang@linux.dev>
next prev parent reply other threads:[~2026-10-15 8:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 11:53 [PATCH] mm/userfaultfd: only allocate anon_vma in CoW mappings David Hildenbrand (Arm)
2026-10-14 14:51 ` Lorenzo Stoakes (ARM)
2026-10-14 18:04 ` Kyle Zeng
2026-10-14 18:29 ` David Hildenbrand (Arm)
2026-10-14 18:29 ` David Hildenbrand (Arm)
2026-10-15 9:05 ` Lorenzo Stoakes (ARM)
2026-10-15 8:16 ` Lance Yang [this message]
2026-10-15 8:33 ` Mike Rapoport
2026-10-15 8:37 ` Muchun Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015081625.4974-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=kylebot@openai.com \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lokeshgidra@google.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.