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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®