Re: [PATCH v2] mm/memfd: fix information leak in hugetlb folios

[Hugh Dickins <hughd@google.com>]

On Wed, 12 Nov 2025, Deepanshu Kartikey wrote:

> When allocating hugetlb folios for memfd, three initialization steps
> are missing:
> 
> 1. Folios are not zeroed, leading to kernel memory disclosure to userspace
> 2. Folios are not marked uptodate before adding to page cache
> 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache()
> 
> The memfd allocation path bypasses the normal page fault handler
> (hugetlb_no_page) which would handle all of these initialization steps.
> This is problematic especially for udmabuf use cases where folios are
> pinned and directly accessed by userspace via DMA.
> 
> Fix by matching the initialization pattern used in hugetlb_no_page():
> - Zero the folio using folio_zero_user() which is optimized for huge pages
> - Mark it uptodate with folio_mark_uptodate()
> - Take hugetlb_fault_mutex before adding to page cache to prevent races
> 
> The folio_zero_user() change also fixes a potential security issue where
> uninitialized kernel memory could be disclosed to userspace through
> read() or mmap() operations on the memfd.
> 
> Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1]
> Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b
> Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")
> Cc: stable@vger.kernel.org
> Suggested-by: Oscar Salvador <osalvador@suse.de>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Tested-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>

Acked-by: Hugh Dickins <hughd@google.com>

Sorry if you were all waiting on a Ack from me.  We're agreed that
the comment above __folio_mark_uptodate() could be deleted, and that
it would be much better if this code can be moved to a shared home
in hugetlb later on; but for now it's more urgent to get this patch
into hotfixes and on to Linus - please Andrew.

Thanks!
Hugh

> ---
> 
> v1 -> v2:
> - Use folio_zero_user() instead of folio_zero_range() (optimized for huge pages)
> - Add folio_mark_uptodate() before adding to page cache
> - Add hugetlb_fault_mutex locking around hugetlb_add_to_page_cache()
> - Add Fixes: tag and Cc: stable for backporting
> - Add Suggested-by: tags for Oscar and David
> ---
>  mm/memfd.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/mm/memfd.c b/mm/memfd.c
> index 1d109c1acf21..d32eef58d154 100644
> --- a/mm/memfd.c
> +++ b/mm/memfd.c
> @@ -96,9 +96,36 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
>  						    NULL,
>  						    gfp_mask);
>  		if (folio) {
> +			u32 hash;
> +
> +			/*
> +			 * Zero the folio to prevent information leaks to userspace.
> +			 * Use folio_zero_user() which is optimized for huge/gigantic
> +			 * pages. Pass 0 as addr_hint since this is not a faulting path
> +			 *  and we don't have a user virtual address yet.
> +			 */
> +			folio_zero_user(folio, 0);
> +
> +			/*
> +			 * Mark the folio uptodate before adding to page cache,
> +			 * as required by filemap.c and other hugetlb paths.
> +			 */
> +			__folio_mark_uptodate(folio);
> +
> +			/*
> +			 * Serialize hugepage allocation and instantiation to prevent
> +			 * races with concurrent allocations, as required by all other
> +			 * callers of hugetlb_add_to_page_cache().
> +			 */
> +			hash = hugetlb_fault_mutex_hash(memfd->f_mapping, idx);
> +			mutex_lock(&hugetlb_fault_mutex_table[hash]);
> +
>  			err = hugetlb_add_to_page_cache(folio,
>  							memfd->f_mapping,
>  							idx);
> +
> +			mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> +
>  			if (err) {
>  				folio_put(folio);
>  				goto err_unresv;
> -- 
> 2.43.0