Re: [PATCH] mm/gup: honour FOLL_PIN in NOMMU __get_user_pages_locked()

David Hildenbrand (Arm)
2026-04-23T12:47:31Z

On 4/23/26 14:31, 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.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Peter Xu <peterx@redhat.com>
> Reported-by: Anthropic
> Assisted-by: gkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> My first foray into -mm, eeek!

Oh, nommu ... what a great use of our time.

I was briefly wondering if we want to add a Fixes: ... but then, this was likely
broken for years and nobody cared so far in practice.

>
> Anyway, this was a crazy report sent to me, and I knocked up this
> change, and I have a reproducer if people need/want to see that as well
> (it's for nommu systems, so be wary of it.)

[...]

> - get_page(pages[i]);
> + if (pages[i]) {
> + /*
> + * pin_user_pages*() arrives here with FOLL_PIN
> + * set; unpin_user_page() (which is not
> + * !CONFIG_MMU-specific) calls
> + * gup_put_folio(..., FOLL_PIN) which subtracts
> + * GUP_PIN_COUNTING_BIAS (1024). A bare
> + * get_page() here adds only 1, so 1023 pins on
> + * a fresh page bring refcount to 1024 and a
> + * single unpin then frees it out from under the
> + * remaining 1022 pins and any live VMA
> + * mappings. Use the same grab path as the MMU
> + * implementation so pin and unpin are
> + * symmetric.
> + */

Yeah, drop all that. Especially the hardcoded 1024/1022 is just screaming for
trouble longterm.

It just follows what we do everywhere else (e.g., follow_page_pte()).

> + if (try_grab_folio(page_folio(pages[i]), 1,
> + foll_flags)) {
> + pages[i] = NULL;
> + break;
> + }
> + }

If it fails on the first iteration, we return -EFAULT instead of -ENOMEM.

I know, I know, nobody cares. But if we touch it, we might just want to return
the error we get from try_grab_folio().

--
Cheers,

David