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 4C2CA2206A7 for ; Wed, 27 May 2026 00:35:51 +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=1779842154; cv=none; b=aH2lYbwpOsh6iozTjr50yi2IbewyQNsQOMzH8Cae994dwQ8yBuGEh/CNdgz87eVCnSZTB7GPIEYpYhtGGMxtkqa4xmyip9AWQtZO9cTWRFa+jOjs506i1K4xoclaGZP2EjwSjQPhMozpY3lNlP7h0BRnaG1YIaWJw1Ej3BspIFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779842154; c=relaxed/simple; bh=1uC7LnV8MjJAf6VGfAwz9rC8yaPJnFbDL7oR5rldl2I=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=XL11CCg1cxufVFliF9mZaL4mxW6jPqsWLutlTZLNpaLC4slaT3CPrEIS6o46+l1mEwiILKDddOo961T6DncyPPe1ZbREwJCm+b01r/FzLwe0HMB00bsAPr6oDoOSjcJ0z5aio5ZP8TE5XVFwQ70r78N/mgnNcsDmVBSCyuqp+s8= 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=0riesBSZ; 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="0riesBSZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E9451F000E9; Wed, 27 May 2026 00:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1779842151; bh=8nAnhYe6Vb6K8/CHU1r82EaNMMrJl0J5U04ISDPErfE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=0riesBSZ8Ui/QdZ3f0Wb2q7DQUO6MHITwZGxhJfUor7uQaCIv2XUhy/+H81xxQ+VM JXFWYM0fhOI+PU4v/qpBQkdkvPt8Ki4AacYwo1+cagyq94hYDCFzZNSJNs71JF7zv8 abZoUNFHEX6RAP9Qr00CNYj3/4+P7isfVN1IRgnI= Date: Tue, 26 May 2026 17:35:50 -0700 From: Andrew Morton To: "David Hildenbrand (Arm)" Cc: Greg Kroah-Hartman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jason Gunthorpe , John Hubbard , Peter Xu Subject: Re: [PATCH v2] mm/gup: honour FOLL_PIN in NOMMU __get_user_pages_locked() Message-Id: <20260526173550.927ba4ba517e9af5a6d2c6bf@linux-foundation.org> In-Reply-To: References: <2026042303-vendor-outright-b9d2@gregkh> <20260424063817.552a894d4b5bfa4de40792fa@linux-foundation.org> 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 Fri, 24 Apr 2026 16:19:32 +0200 "David Hildenbrand (Arm)" wrote: > On 4/24/26 15:38, Andrew Morton wrote: > > On Thu, 23 Apr 2026 16:28:04 +0200 Greg Kroah-Hartman wrote: > > > >> The !CONFIG_MMU implementation of __get_user_pages_locked() takes a bare > >> get_page() reference for each page regardless of foll_flags: > >> if (pages[i]) > >> get_page(pages[i]); > >> > >> This is reached from pin_user_pages*() with FOLL_PIN set. > >> unpin_user_page() is shared between MMU and NOMMU configurations and > >> unconditionally calls gup_put_folio(..., FOLL_PIN), which subtracts > >> GUP_PIN_COUNTING_BIAS (1024) from the folio refcount. > >> > >> This means that pin adds 1, and then unpin will subtract 1024. > >> > >> If a user maps a page (refcount 1), registers it 1023 times as an > >> io_uring fixed buffer (1023 pin_user_pages calls -> refcount 1024), then > >> unregisters: the first unpin_user_page subtracts 1024, refcount hits 0, > >> the page is freed and returned to the buddy allocator. The remaining > >> 1022 unpins write into whatever was reallocated, and the user's VMA > >> still maps the freed page (NOMMU has no MMU to invalidate it). > >> Reallocating the page for an io_uring pbuf_ring then lets userspace > >> corrupt the new owner's data through the stale mapping. > >> > >> Use try_grab_folio() which adds GUP_PIN_COUNTING_BIAS for FOLL_PIN and 1 > >> for FOLL_GET, mirroring the CONFIG_MMU path so pin and unpin are > >> symmetric. > > > > Battle of the bots? > > https://sashiko.dev/#/patchset/2026042303-vendor-outright-b9d2@gregkh > > It references the > > if (pages && !(flags & FOLL_PIN)) > flags |= FOLL_GET; > > I'm not sure if there is actual NOMMU code that triggers it. For example, > uprobes uses that pattern, but I suspect that that's not a thing on NOMMU. > > > Probably best to just squash: > > diff --git a/mm/gup.c b/mm/gup.c > index ad9ded39609c..44bd28cf6e00 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1988,6 +1988,9 @@ static long __get_user_pages_locked(struct mm_struct *mm, > unsigned long start, > if (!nr_pages) > return 0; > > + if (pages && !(foll_flags & FOLL_PIN)) > + foll_flags |= FOLL_GET; > + > /* > * The internal caller expects GUP to manage the lock internally and the > * lock must be released when this returns. Nothing happened. Should we proceed with this as-is? From: Greg Kroah-Hartman Subject: mm/gup: honour FOLL_PIN in NOMMU __get_user_pages_locked() Date: Thu, 23 Apr 2026 16:28:04 +0200 The !CONFIG_MMU implementation of __get_user_pages_locked() takes a bare get_page() reference for each page regardless of foll_flags: if (pages[i]) get_page(pages[i]); This is reached from pin_user_pages*() with FOLL_PIN set. unpin_user_page() is shared between MMU and NOMMU configurations and unconditionally calls gup_put_folio(..., FOLL_PIN), which subtracts GUP_PIN_COUNTING_BIAS (1024) from the folio refcount. This means that pin adds 1, and then unpin will subtract 1024. If a user maps a page (refcount 1), registers it 1023 times as an io_uring fixed buffer (1023 pin_user_pages calls -> refcount 1024), then unregisters: the first unpin_user_page subtracts 1024, refcount hits 0, the page is freed and returned to the buddy allocator. The remaining 1022 unpins write into whatever was reallocated, and the user's VMA still maps the freed page (NOMMU has no MMU to invalidate it). Reallocating the page for an io_uring pbuf_ring then lets userspace corrupt the new owner's data through the stale mapping. Use try_grab_folio() which adds GUP_PIN_COUNTING_BIAS for FOLL_PIN and 1 for FOLL_GET, mirroring the CONFIG_MMU path so pin and unpin are symmetric. While at it, don't return NULL pointers in the page array, as this is really not expected for GUP users; instead, just fail and return -EFAULT. [david@kernel.org: changelog update] https://lore.kernel.org/e9c5cf89-fa4c-4b83-ae70-9d3c72542ee9@kernel.org Link: https://lore.kernel.org/2026042303-vendor-outright-b9d2@gregkh Signed-off-by: Greg Kroah-Hartman Acked-by: David Hildenbrand (Arm) Assisted-by: David Hildenbrand Cc: Jason Gunthorpe Cc: John Hubbard Cc: Peter Xu Reported-by: Anthropic Assisted-by: gkh_clanker_t1000 Cc: Signed-off-by: Andrew Morton --- mm/gup.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- a/mm/gup.c~mm-gup-honour-foll_pin-in-nommu-__get_user_pages_locked +++ a/mm/gup.c @@ -1983,6 +1983,7 @@ static long __get_user_pages_locked(stru struct vm_area_struct *vma; bool must_unlock = false; vm_flags_t vm_flags; + int ret, err = -EFAULT; long i; if (!nr_pages) @@ -2019,8 +2020,14 @@ static long __get_user_pages_locked(stru if (pages) { pages[i] = virt_to_page((void *)start); - if (pages[i]) - get_page(pages[i]); + if (!pages[i]) + break; + ret = try_grab_folio(page_folio(pages[i]), 1, foll_flags); + if (unlikely(ret)) { + pages[i] = NULL; + err = ret; + break; + } } start = (start + PAGE_SIZE) & PAGE_MASK; @@ -2031,7 +2038,7 @@ static long __get_user_pages_locked(stru *locked = 0; } - return i ? : -EFAULT; + return i ? : err; } #endif /* !CONFIG_MMU */ _