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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aRXJN2WHvfAwoAFE@localhost.localdomain>
Date: Thu, 13 Nov 2025 13:04:07 +0100
From: Oscar Salvador <osalvador@...e.de>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: hughd@...gle.com, baolin.wang@...ux.alibaba.com,
	akpm@...ux-foundation.org, david@...hat.com, muchun.song@...ux.dev,
	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, Nov 12, 2025 at 08:20:34PM +0530, 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>

As David mentioned, we can drop the comment wrt. __folio_mark_uptodate.
As for the addr_hint in folio_zero_user, I do not think it makes a
difference in here.
AFAIK, it serves the purpose that subpages belong to the addr_hint will
be zeroed the latest to keep them in cache, but here it does not really
apply, so '0' should just work?

Acked-by: Oscar Salvador <osalvador@...e.de>


-- 
Oscar Salvador
SUSE Labs