Re: [PATCH] mm/memfd: clear hugetlb pages on allocation

[Hugh Dickins <hughd@google.com>]

On Wed, 12 Nov 2025, Deepanshu Kartikey wrote:

> When allocating hugetlb pages for memfd, the pages are not zeroed,
> which leads to uninitialized kernel memory being exposed to userspace
> through read() or mmap() operations.
> 
> The issue arises because hugetlb_reserve_pages() can allocate pages
> through the surplus allocation path without the __GFP_ZERO flag. These
> pages are added to the reservation pool and later returned by
> alloc_hugetlb_folio_reserve() without being cleared, resulting in
> uninitialized memory being accessible to userspace.
> 
> This is a security vulnerability as it allows information disclosure of
> potentially sensitive kernel data. Fix it by explicitly zeroing the
> folio after allocation using folio_zero_range().
> 
> This is particularly important for udmabuf use cases where these pages
> are pinned and directly accessed by userspace via DMA buffers.
> 
> Reproducer:
>  - Create memfd with MFD_HUGETLB flag
>  - Use UDMABUF_CREATE ioctl to pin the hugetlb pages
>  - Read from the memfd using preadv()
>  - KMSAN detects uninitialized memory being copied to userspace
> 
> Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b
> Tested-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>

Thanks a lot, Deepanshu and syzbot: this sounds horrid, and important
to fix very soon; and wlll need a Fixes tag (with stable Cc'ed when
the fix goes into mm.git), I presume it's

Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")

But although my name appears against mm/memfd.c, the truth is I know
little of hugetlb (maintainers now addressed), and when its folios
are supposed to get zeroed (would a __GFP_ZERO somewhere be better?).

I was puzzled by how udmabuf came into the picture, since hugetlbfs
has always supported the read (not write) system call: but see now
that there is this surprising backdoor into the hugetlb subsystem,
via memfd and GUP pinning.

And where does that folio get marked uptodate, or is "uptodate"
irrelevant on hugetlbfs?  Are the right locks taken, or could
there be races when adding to hugetlbfs cache in this way?

Muchun, Oscar, David, I think this needs your eyes please!  I sense
that there could easily be other bugs hereabouts, but perhaps the
lack of zeroing needs to be addressed before worrying further.

Thanks,
Hugh

> ---
>  mm/memfd.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/memfd.c b/mm/memfd.c
> index 1d109c1acf21..f8cfc2909507 100644
> --- a/mm/memfd.c
> +++ b/mm/memfd.c
> @@ -96,6 +96,12 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
>  						    NULL,
>  						    gfp_mask);
>  		if (folio) {
> +			/*
> +			 * Zero the folio to prevent information leaks to userspace.
> +			 * The folio may have been allocated during hugetlb_reserve_pages()
> +			 * without __GFP_ZERO, so explicitly clear it here.
> +			 */
> +			folio_zero_range(folio, 0, folio_size(folio));
>  			err = hugetlb_add_to_page_cache(folio,
>  							memfd->f_mapping,
>  							idx);
> -- 
> 2.43.0