From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4048F30170F for ; Sun, 28 Jun 2026 20:53:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782680024; cv=none; b=tDjdgxkoZ/yhCBVc2F8MX/TACvoeJSn/sfO9oNEIsOakhUb54hVTqld9lo7dKLzKtBg3qSj9evsn5LCtqW7N5wTe90/v4ryFyN7SulopYk3D+RS2/hyh1ePy041FGfFxyZoCjZvNaEuKXmkQxGJXZ+TLGh8PEz9IG8yJoEIX+6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782680024; c=relaxed/simple; bh=zq35yqyAvS6JrAaAQh/rAjyDxPqpO/SM4Vz1FN8QzrA=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=aZJ39c+dQ1UiKrR+iwoR9jKKXCPPCgRFx6RODtM305uT+2oqNN+iqcc45CiorpbW+QAEfrddrfiMnm4JU34hlxJp8iJM72Tdn7+KUAt9AYKUM7b13D11v6IRrWBtBHwp5pmptApzsQiE5J6TDVyZ2dROSjX4x7Ey04yekaqSNvA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=aUloFBqh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="aUloFBqh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D98B1F000E9; Sun, 28 Jun 2026 20:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1782680022; bh=43Qp/DZkFZa4pSVmpAAZCxaCea3bWSVMtuT4gbAZk+M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=aUloFBqhNDK4cnV6TVf93MMmYU7EzVvmfAA0r7uGl13Cv//sukiUTm9edFpINIiWn +GHeqFIWXdpff++K7SP6GuDOEJwo4BLORaVMgrUoArCUCb0ELZGnYOlAxJytLHnbDg apMSmgEtEEFKVSK/dOv1TSLQ0rbP3BB6op5EGJeQ= Date: Sun, 28 Jun 2026 13:53:42 -0700 From: Andrew Morton To: Jianhui Zhou Cc: rppt@kernel.org, linux-mm@kvack.org, peterx@redhat.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, syzbot+18d274a59b87cf80e86d@syzkaller.appspotmail.com Subject: Re: [PATCH] mm/userfaultfd: clear uffd-wp PTE state when re-registering without WP Message-Id: <20260628135342.21cb90a7a559d36bb629802c@linux-foundation.org> In-Reply-To: <20260601082609.170076-1-jianhuizzzzz@gmail.com> References: <20260601082609.170076-1-jianhuizzzzz@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 1 Jun 2026 16:26:09 +0800 Jianhui Zhou wrote: > UFFDIO_REGISTER can be issued on a range that is already registered in > the same userfaultfd context, replacing the VMA's userfaultfd tracking > mode. For example, a range can be registered with > UFFDIO_REGISTER_MODE_WP and later re-registered with > UFFDIO_REGISTER_MODE_MISSING. > > When the second registration removes VM_UFFD_WP, the VMA flags are > updated but existing uffd-wp state in page-table entries is left behind. > That stale state can survive in swap PTEs. On swapin, do_swap_page() > restores _PAGE_UFFD_WP from the swap PTE and can then install a writable > PTE, triggering page_table_check: > > pte_uffd_wp(pte) && pte_write(pte) > > Handle removal of WP mode through UFFDIO_REGISTER the same way as > UFFDIO_UNREGISTER: resolve the per-PTE uffd-wp state before dropping > VM_UFFD_WP from the VMA. > > Also make the same-context fast path require an exact UFFD mode match. > The old subset check treats MISSING|WP -> MISSING as a no-op, even though > WP mode is being removed. Thanks. > Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration") > Reported-by: syzbot+18d274a59b87cf80e86d@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=18d274a59b87cf80e86d So we have a WARN which can be triggered by unprivileged userspace. The patch arrived during -rc6 when people were reviewing and testing material for the next merge window, rather than looking at new changes. > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -2153,13 +2153,21 @@ int userfaultfd_register_range(struct userfaultfd_ctx *ctx, > * userfaultfd and with the right tracking mode too. > */ > if (vma->vm_userfaultfd_ctx.ctx == ctx && > - vma_test_all_mask(vma, vma_flags)) > + (vma->vm_flags & __VM_UFFD_FLAGS) == vm_flags) > goto skip; > > if (vma->vm_start > start) > start = vma->vm_start; > vma_end = min(end, vma->vm_end); > > + /* > + * Re-registering into the same userfaultfd can remove WP mode. > + * Clear any per-PTE uffd-wp state before dropping VM_UFFD_WP, > + * matching the UFFDIO_UNREGISTER cleanup semantics. > + */ > + if (userfaultfd_wp(vma) && !(vm_flags & VM_UFFD_WP)) > + uffd_wp_range(vma, start, vma_end - start, false); > + > new_vma_flags = vma->flags; > vma_flags_clear_mask(&new_vma_flags, __VMA_UFFD_FLAGS); > vma_flags_set_mask(&new_vma_flags, vma_flags); I'll queue this for 7.3-rc1, with a cc:stable. f45ec5ff16a7 was 6 years ago, so there's no rush here. I don't know if this is the best fix, so I'll await reviewer input before taking it any further.