[syzbot] [fs?] [mm?] KMSAN: kernel-infoleak in hugetlbfs_read_iter

[syzbot] [fs?] [mm?] KMSAN: kernel-infoleak in hugetlbfs_read_iter

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    439fc29dfd3b Merge tag 'drm-fixes-2025-11-09' of https://g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14c7517c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=cbf50e713aaa5cb0
dashboard link: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=107f3084580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10634b42580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/cfc76859b0d7/disk-439fc29d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1a4aa2e08e02/vmlinux-439fc29d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/24591c797483/bzImage-439fc29d.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com

=====================================================
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak in iterate_iovec include/linux/iov_iter.h:52 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:304 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:330 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4e4/0x33f0 lib/iov_iter.c:185
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 copy_to_user_iter lib/iov_iter.c:24 [inline]
 iterate_iovec include/linux/iov_iter.h:52 [inline]
 iterate_and_advance2 include/linux/iov_iter.h:304 [inline]
 iterate_and_advance include/linux/iov_iter.h:330 [inline]
 _copy_to_iter+0x4e4/0x33f0 lib/iov_iter.c:185
 copy_page_to_iter+0x482/0x910 lib/iov_iter.c:362
 copy_folio_to_iter include/linux/uio.h:204 [inline]
 hugetlbfs_read_iter+0x6cd/0xe10 fs/hugetlbfs/inode.c:281
 do_iter_readv_writev+0x9e1/0xc20 fs/read_write.c:-1
 vfs_readv+0x34a/0xf30 fs/read_write.c:1018
 do_preadv fs/read_write.c:1132 [inline]
 __do_sys_preadv fs/read_write.c:1179 [inline]
 __se_sys_preadv fs/read_write.c:1174 [inline]
 __x64_sys_preadv+0x2a3/0x510 fs/read_write.c:1174
 x64_sys_call+0x3064/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:296
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 __alloc_frozen_pages_noprof+0x689/0xf00 mm/page_alloc.c:5206
 alloc_buddy_hugetlb_folio mm/hugetlb.c:1944 [inline]
 only_alloc_fresh_hugetlb_folio+0x2b0/0x1280 mm/hugetlb.c:1984
 alloc_fresh_hugetlb_folio mm/hugetlb.c:2003 [inline]
 alloc_surplus_hugetlb_folio+0x178/0x5c0 mm/hugetlb.c:2223
 gather_surplus_pages mm/hugetlb.c:2415 [inline]
 hugetlb_acct_memory+0x759/0x2420 mm/hugetlb.c:5331
 hugetlb_reserve_pages+0x10d1/0x26f0 mm/hugetlb.c:7347
 memfd_alloc_folio+0x20a/0x7b0 mm/memfd.c:90
 memfd_pin_folios+0x10b3/0x16a0 mm/gup.c:3523
 udmabuf_pin_folios drivers/dma-buf/udmabuf.c:337 [inline]
 udmabuf_create+0x1256/0x1ed0 drivers/dma-buf/udmabuf.c:434
 udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:486 [inline]
 udmabuf_ioctl+0x2eb/0x5b0 drivers/dma-buf/udmabuf.c:517
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl+0x23c/0x400 fs/ioctl.c:583
 __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:583
 x64_sys_call+0x1cbc/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:17
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Bytes 0-5 of 6 are uninitialized
Memory access of size 6 starts at ffff88804480000f
Data copied to user address 0000200000000080

CPU: 0 UID: 0 PID: 6052 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(none) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Forwarded: [PATCH] mm/memfd: zero hugetlb pages on allocation

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/memfd: zero hugetlb pages on allocation
Author: kartikey406@gmail.com

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


When allocating hugetlb pages for memfd, the pages were not being
zeroed, which could lead to uninitialized kernel memory being exposed
to userspace through read() or mmap() operations.

This is a security issue as it allows information disclosure of
potentially sensitive kernel data. Add __GFP_ZERO to the gfp_mask
to ensure pages are cleared before being made accessible to userspace.

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 ioctl to pin the pages
 - Read from the memfd using preadv()
 - KMSAN detects uninitialized memory leak to userspace

Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 mm/memfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/memfd.c b/mm/memfd.c
index 1d109c1acf21..0095b9f4fe00 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -85,6 +85,7 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
 
 		gfp_mask = htlb_alloc_mask(h);
 		gfp_mask &= ~(__GFP_HIGHMEM | __GFP_MOVABLE);
+		gfp_mask |= __GFP_ZERO;
 		idx >>= huge_page_order(h);
 
 		nr_resv = hugetlb_reserve_pages(inode, idx, idx + 1, NULL, 0);
-- 
2.43.0

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

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/memfd: clear hugetlb pages on allocation
Author: kartikey406@gmail.com

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

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
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 mm/memfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/memfd.c b/mm/memfd.c
index 1d109c1acf21..cdef16ef1011 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -96,6 +96,7 @@ struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx)
 						    NULL,
 						    gfp_mask);
 		if (folio) {
+			folio_zero_range(folio, 0, folio_size(folio));
 			err = hugetlb_add_to_page_cache(folio,
 							memfd->f_mapping,
 							idx);
-- 
2.43.0

Forwarded: [PATCH] mm/memfd: properly initialize hugetlb folios

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/memfd: properly initialize hugetlb folios
Author: kartikey406@gmail.com

#syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


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 fixes a security vulnerability where
uninitialized kernel memory could be disclosed to userspace through
read() or mmap() operations on the memfd.

Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/
Reported-by: syzbot+f64019ba229e3a5c411b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b
Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")
Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1]
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v1 -> v2:
- Use folio_zero_user() instead of folio_zero_range() per David's feedback
- Add __folio_mark_uptodate() before adding to page cache per Oscar's feedback
- Add hugetlb_fault_mutex locking around hugetlb_add_to_page_cache() per Oscar's feedback
- Add Fixes: tag and Cc: stable for backporting per Hugh's feedback
- 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