[PATCH] mm/hugetlb: Don't crash when allocating a folio if there are no resv

[Kasireddy, Vivek]

Hi Oscar,

> Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if there
> are no resv
> 
> On Tue, Jun 17, 2025 at 10:28:40PM -0700, Vivek Kasireddy wrote:
> > There are cases when we try to pin a folio but discover that it has
> > not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
> > but there is a chance that we might encounter a fatal crash/failure
> > (VM_BUG_ON(!h->resv_huge_pages) in alloc_hugetlb_folio_reserve()) if
> > there are no active reservations at that instant. This issue was
> > reported by syzbot:
> >
> > kernel BUG at mm/hugetlb.c:2403!
> > Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > CPU: 0 UID: 0 PID: 5315 Comm: syz.0.0 Not tainted
> > 6.13.0-rc5-syzkaller-00161-g63676eefb7a0 #0
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> > 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> > RIP: 0010:alloc_hugetlb_folio_reserve+0xbc/0xc0 mm/hugetlb.c:2403
> > Code: 1f eb 05 e8 56 18 a0 ff 48 c7 c7 40 56 61 8e e8 ba 21 cc 09 4c 89
> > f0 5b 41 5c 41 5e 41 5f 5d c3 cc cc cc cc e8 35 18 a0 ff 90 <0f> 0b 66
> > 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
> > RSP: 0018:ffffc9000d3d77f8 EFLAGS: 00010087
> > RAX: ffffffff81ff6beb RBX: 0000000000000000 RCX: 0000000000100000
> > RDX: ffffc9000e51a000 RSI: 00000000000003ec RDI: 00000000000003ed
> > RBP: 1ffffffff34810d9 R08: ffffffff81ff6ba3 R09: 1ffffd4000093005
> > R10: dffffc0000000000 R11: fffff94000093006 R12: dffffc0000000000
> > R13: dffffc0000000000 R14: ffffea0000498000 R15: ffffffff9a4086c8
> > FS:  00007f77ac12e6c0(0000) GS:ffff88801fc00000(0000)
> > knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f77ab54b170 CR3: 0000000040b70000 CR4: 0000000000352ef0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >  <TASK>
> >  memfd_alloc_folio+0x1bd/0x370 mm/memfd.c:88
> >  memfd_pin_folios+0xf10/0x1570 mm/gup.c:3750
> >  udmabuf_pin_folios drivers/dma-buf/udmabuf.c:346 [inline]
> >  udmabuf_create+0x70e/0x10c0 drivers/dma-buf/udmabuf.c:443
> >  udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:495 [inline]
> >  udmabuf_ioctl+0x301/0x4e0 drivers/dma-buf/udmabuf.c:526
> >  vfs_ioctl fs/ioctl.c:51 [inline]
> >  __do_sys_ioctl fs/ioctl.c:906 [inline]
> >  __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
> >  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> >  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Therefore, prevent the above crash by replacing the VM_BUG_ON()
> > with WARN_ON_ONCE() as there is no need to crash the system in
> > this situation and instead we could just warn and fail the
> > allocation.
> >
> > Fixes: 26a8ea80929c ("mm/hugetlb: fix memfd_pin_folios resv_huge_pages
> leak")
> > Reported-by: syzbot+a504cb5bae4fe117ba94 at syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=a504cb5bae4fe117ba94
> > Cc: Steve Sistare <steven.sistare at oracle.com>
> > Cc: Muchun Song <muchun.song at linux.dev>
> > Cc: David Hildenbrand <david at redhat.com>
> > Cc: Andrew Morton <akpm at linux-foundation.org>
> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy at intel.com>
> 
> Who is supossed to reserve these hugepages?
> hugetlb_reserve_pages() is only called at mmap/file setup, and you mention
> that
> you try to allocate the folios even before mmap, so who's in charge of
> making those reservations for you?
In this specific case, I would say the caller (memfd_alloc_folio()) should be the
one making the reservation before it tries to allocate the folio. And, the other
series you commented on is trying to do just that.

However, as mentioned in the other thread (replying to Andrew and Anshuman),
this is a very uncommon use-case as hugetlbfs_file_mmap() is not called first.
So, this patch is only trying to prevent the crash but the actual underlying problem
(no reservation) is addressed in the other series.

Thanks,
Vivek

> 
> 
> 
> --
> Oscar Salvador
> SUSE Labs