From: Tal Zussman <tz2294@columbia.edu>
To: Andrew Morton <akpm@linux-foundation.org>,
Peter Xu <peterx@redhat.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
David Hildenbrand <david@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Tal Zussman <tz2294@columbia.edu>
Subject: [PATCH v2 3/4] userfaultfd: prevent unregistering VMAs through a different userfaultfd
Date: Sat, 07 Jun 2025 02:40:02 -0400 [thread overview]
Message-ID: <20250607-uffd-fixes-v2-3-339dafe9a2fe@columbia.edu> (raw)
In-Reply-To: <20250607-uffd-fixes-v2-0-339dafe9a2fe@columbia.edu>
Currently, a VMA registered with a uffd can be unregistered through a
different uffd associated with the same mm_struct.
The existing behavior is slightly broken and may incorrectly reject
unregistering some VMAs due to the following check:
if (!vma_can_userfault(cur, cur->vm_flags, wp_async))
goto out_unlock;
where wp_async is derived from ctx, not from cur. For example, a file-backed
VMA registered with wp_async enabled and UFFD_WP mode cannot be unregistered
through a uffd that does not have wp_async enabled.
Rather than fix this and maintain this odd behavior, make unregistration
stricter by requiring VMAs to be unregistered through the same uffd they
were registered with. Additionally, reorder the WARN() checks to avoid
the aforementioned wp_async issue in the WARN()s.
This change slightly modifies the ABI. It should not be backported to
-stable.
While at it, correct the comment for the no userfaultfd case. This seems to
be a copy-paste artifact from the analogous userfaultfd_register() check.
Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
---
fs/userfaultfd.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 80c95c712266..10e8037f5216 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -1466,6 +1466,16 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx,
VM_WARN_ON_ONCE(!!cur->vm_userfaultfd_ctx.ctx ^
!!(cur->vm_flags & __VM_UFFD_FLAGS));
+ /*
+ * Check that this VMA isn't already owned by a different
+ * userfaultfd. This provides for more strict behavior by
+ * preventing a VMA registered with a userfaultfd from being
+ * unregistered through a different userfaultfd.
+ */
+ if (cur->vm_userfaultfd_ctx.ctx &&
+ cur->vm_userfaultfd_ctx.ctx != ctx)
+ goto out_unlock;
+
/*
* Check not compatible vmas, not strictly required
* here as not compatible vmas cannot have an
@@ -1489,15 +1499,14 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx,
for_each_vma_range(vmi, vma, end) {
cond_resched();
- VM_WARN_ON_ONCE(!vma_can_userfault(vma, vma->vm_flags, wp_async));
-
/*
- * Nothing to do: this vma is already registered into this
- * userfaultfd and with the right tracking mode too.
+ * Nothing to do: this vma is not registered with userfaultfd.
*/
if (!vma->vm_userfaultfd_ctx.ctx)
goto skip;
+ VM_WARN_ON_ONCE(vma->vm_userfaultfd_ctx.ctx != ctx);
+ VM_WARN_ON_ONCE(!vma_can_userfault(vma, vma->vm_flags, wp_async));
WARN_ON(!(vma->vm_flags & VM_MAYWRITE));
if (vma->vm_start > start)
--
2.39.5
next prev parent reply other threads:[~2025-06-07 6:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-07 6:39 [PATCH v2 0/4] mm: userfaultfd: assorted fixes and cleanups Tal Zussman
2025-06-07 6:40 ` [PATCH v2 1/4] userfaultfd: correctly prevent registering VM_DROPPABLE regions Tal Zussman
2025-06-07 14:40 ` Jason A. Donenfeld
2025-06-07 22:04 ` Andrew Morton
2025-06-09 15:02 ` Peter Xu
2025-06-07 6:40 ` [PATCH v2 2/4] userfaultfd: remove (VM_)BUG_ON()s Tal Zussman
2025-06-10 7:26 ` David Hildenbrand
2025-06-17 23:10 ` Tal Zussman
2025-06-23 15:18 ` David Hildenbrand
2025-06-10 13:11 ` Peter Xu
2025-06-10 13:17 ` David Hildenbrand
2025-06-07 6:40 ` Tal Zussman [this message]
2025-06-10 7:30 ` [PATCH v2 3/4] userfaultfd: prevent unregistering VMAs through a different userfaultfd David Hildenbrand
2025-06-17 20:50 ` Tal Zussman
2025-06-07 6:40 ` [PATCH v2 4/4] userfaultfd: remove UFFD_CLOEXEC, UFFD_NONBLOCK, and UFFD_FLAGS_SET Tal Zussman
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=20250607-uffd-fixes-v2-3-339dafe9a2fe@columbia.edu \
--to=tz2294@columbia.edu \
--cc=Jason@zx2c4.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=david@redhat.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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