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

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: <6d104efa-0686-4621-aba1-3ce17ef85391@kernel.org>
Date: Thu, 13 Nov 2025 10:20:30 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Deepanshu Kartikey <kartikey406@...il.com>, hughd@...gle.com,
 baolin.wang@...ux.alibaba.com, akpm@...ux-foundation.org,
 muchun.song@...ux.dev, osalvador@...e.de
Cc: 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 12.11.25 15:50, 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>
> ---
> 
> 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);

Staring at hugetlbfs_fallocate(), we see, to pass the offset within the 
file.

I think it shouldn't make a difference here (I don't see how the offset 
in the file would be better than 0: it's in both cases not the user 
address).

> +
> +			/*
> +			 * Mark the folio uptodate before adding to page cache,
> +			 * as required by filemap.c and other hugetlb paths.
> +			 */
> +			__folio_mark_uptodate(folio);

Personally, I'd drop this comment as it is really just doing what we do 
everywhere else :)

Hoping we can factor that out into hugetlb code properly.

Acked-by: David Hildenbrand (Red Hat) <david@...nel.org>

-- 
Cheers

David