From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D58E82C3259 for ; Thu, 9 Apr 2026 17:04:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754292; cv=none; b=TsVlm/5i44j3I1LtBL/t7rePzJB1NCdSvr5nxJau8csPwaK4Tc/iIdw6vYdVLrf0FQ2bXUUUpGmqn64GJdnzVS+GjIc0Deits/qjgHgEAJVJJk3qyRB6tR1YTKxM6cYG4Uy6WVUlHQI/1D250kasgqSyRsd3HWQslIU0fvIPcK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775754292; c=relaxed/simple; bh=SNp5Dca2WkR7m+cZfnjJ08JI2QTkKbVMIgFIL0NCEFE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Lvz/A+J0/1tVqbr4mUAkt6EK6u5KcsVjXzD1Vl2HiUEK6wRIrY53M1SwYzUJcGB7dy9DbL0z242Wy7/DEKGtYIzb53FpKSXFVdFfrAnXkxAyU6bl+v/46gG7n4E4xXHdrZVe+/pDxcHUlZD3vTaGEcpEGG5RWFnkIiQckSNs0E0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BuFnRLrC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BuFnRLrC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6989C4CEF7; Thu, 9 Apr 2026 17:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775754292; bh=SNp5Dca2WkR7m+cZfnjJ08JI2QTkKbVMIgFIL0NCEFE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BuFnRLrCwQF8NSp2qmLtteCUTqxnummyH9ZdjP84VJaLdvDn09YVcg7dshUyoc0Wu hyHfGrm+fMI9YyITE3P6RtG7MPc6rVqL/7Wk884lOXmyGRhu2b4/Fx8wkfNBxkM9US j+rv3qits0ZUeTdnQQgen9jhsnp+oi4imuxyzSJ7mzftaVL+/+hDMx+r2FZdUxAozH HhKrcoutX0VHIh4Mh3RZ+gmn68twsaC8ZW1xvQuTiev2WGB8/pahEubDNbYoVQxrcI IM7AXKs8jAffgJcGsvFN5DFCIfNCmW4Y27OhGasjgKogSS+bpch4hn90sOcOtbBG5R 65e7u1Fl4w8kA== Message-ID: Date: Thu, 9 Apr 2026 19:04:49 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry() Content-Language: en-US To: David Carlier , Andrew Morton , Mike Rapoport , Peter Xu Cc: "Liam R . Howlett" , Lorenzo Stoakes , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260409120653.290386-1-devnexen@gmail.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260409120653.290386-1-devnexen@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/9/26 14:06, David Carlier wrote: > mfill_copy_folio_retry() drops mmap_lock for the copy_from_user() call. > During this window, the VMA can be replaced with a different type (e.g. > hugetlb), making the caller's ops pointer stale. Subsequent use of the > stale ops can lead to incorrect folio handling or a kernel crash. > > Pass the caller's ops into mfill_copy_folio_retry() and compare against > the current vma_uffd_ops() after re-acquiring the lock. Return -EAGAIN > if they differ so the operation can be retried. > > Fixes: 59da5c32ffa3 ("userfaultfd: mfill_atomic(): remove retry logic") I don't have such sha1, is it a stale mm-unstable commit? Seems to be 4974a6aaa768 ("userfaultfd: mfill_atomic(): remove retry logic") now in mm-unstable (and can further change) > Signed-off-by: David Carlier > --- > mm/userfaultfd.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 481ec7eb4442..214923a411c1 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -443,7 +443,9 @@ static int mfill_copy_folio_locked(struct folio *folio, unsigned long src_addr) > return ret; > } > > -static int mfill_copy_folio_retry(struct mfill_state *state, struct folio *folio) > +static int mfill_copy_folio_retry(struct mfill_state *state, > + const struct vm_uffd_ops *ops, > + struct folio *folio) > { > unsigned long src_addr = state->src_addr; > void *kaddr; > @@ -465,6 +467,14 @@ static int mfill_copy_folio_retry(struct mfill_state *state, struct folio *folio > if (err) > return err; > > + /* > + * The VMA type may have changed while the lock was dropped > + * (e.g. replaced with a hugetlb mapping), making the caller's > + * ops pointer stale. > + */ > + if (vma_uffd_ops(state->vma) != ops) > + return -EAGAIN; > + > err = mfill_establish_pmd(state); > if (err) > return err; > @@ -495,7 +505,7 @@ static int __mfill_atomic_pte(struct mfill_state *state, > * will take care of unlocking if needed. > */ > if (unlikely(ret)) { > - ret = mfill_copy_folio_retry(state, folio); > + ret = mfill_copy_folio_retry(state, ops, folio); > if (ret) > goto err_folio_put; > }