lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4319c8a-4e81-00de-f184-844348d85681@google.com>
Date: Sat, 22 Nov 2025 21:03:07 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>, 
    Deepanshu Kartikey <kartikey406@...il.com>
cc: hughd@...gle.com, baolin.wang@...ux.alibaba.com, david@...hat.com, 
    muchun.song@...ux.dev, osalvador@...e.de, kraxel@...hat.com, 
    airlied@...hat.com, jgg@...pe.ca, linux-mm@...ck.org, 
    linux-kernel@...r.kernel.org, vivek.kasireddy@...el.com, 
    syzbot+f64019ba229e3a5c411b@...kaller.appspotmail.com, 
    stable@...r.kernel.org
Subject: Re: [PATCH v2] mm/memfd: fix information leak in hugetlb folios

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@...kaller.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@...r.kernel.org
> Suggested-by: Oscar Salvador <osalvador@...e.de>
> Suggested-by: David Hildenbrand <david@...hat.com>
> Tested-by: syzbot+f64019ba229e3a5c411b@...kaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>

Acked-by: Hugh Dickins <hughd@...gle.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ