Re: [syzbot] [mm?] kernel BUG in __khugepaged_enter

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Mon, Feb 16, 2026 at 03:40:21PM +0100, David Hildenbrand (Arm) wrote:
> On 2/14/26 17:40, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    1e83ccd5921a sched/mmcid: Don't assume CID is CPU owned on..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1169dae6580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=54ae71b284dd0e13
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6b554d491efbe066b701
> > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/ed43f42e3ea1/disk-1e83ccd5.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/d8af54a32588/vmlinux-1e83ccd5.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/34e6a8cc1037/bzImage-1e83ccd5.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+6b554d491efbe066b701@syzkaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > kernel BUG at mm/khugepaged.c:438!
> > Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
> > CPU: 0 UID: 0 PID: 16472 Comm: syz.3.2372 Tainted: G     U  W    L XTNJ syzkaller #0 PREEMPT(full)
> > Tainted: [U]=USER, [W]=WARN, [L]=SOFTLOCKUP, [X]=AUX, [T]=RANDSTRUCT, [N]=TEST, [J]=FWCTL
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
> > RIP: 0010:__khugepaged_enter+0x30a/0x380 mm/khugepaged.c:438
> > Code: 64 7e 8e e8 a8 dc 66 ff e8 93 e6 8d ff 5b 5d 41 5c 41 5d 41 5e 41 5f e9 04 6c 04 09 e8 7f e6 8d ff 48 89 df e8 17 33 d9 ff 90 <0f> 0b 48 89 ef e8 dc 51 f8 ff e9 3b fd ff ff e8 f2 52 f8 ff e9 e1
> > RSP: 0018:ffffc9000e98fba8 EFLAGS: 00010292
> > RAX: 000000000000031f RBX: ffff888079b24980 RCX: 0000000000000000
> > RDX: 000000000000031f RSI: ffffffff81e5b2c9 RDI: fffff52001d31f1c
> > RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
> > R10: 0000000080000000 R11: 0000000000000001 R12: 0000000008100177
> > R13: ffff88804adf9510 R14: 0000000000000000 R15: 0000000000000000
> > FS:  00007f06093436c0(0000) GS:ffff8881245b1000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fff341d3f52 CR3: 00000000319b0000 CR4: 00000000003526f0
> > Call Trace:
> >   <TASK>
> >   khugepaged_enter_vma mm/khugepaged.c:467 [inline]
> >   khugepaged_enter_vma+0x137/0x2c0 mm/khugepaged.c:461
> >   do_huge_pmd_anonymous_page+0x1c8/0x1c00 mm/huge_memory.c:1469
> >   create_huge_pmd mm/memory.c:6102 [inline]
> >   __handle_mm_fault+0x1e96/0x2b50 mm/memory.c:6376
> >   handle_mm_fault+0x36d/0xa20 mm/memory.c:6583
> >   do_user_addr_fault+0x5a3/0x12f0 arch/x86/mm/fault.c:1334
> >   handle_page_fault arch/x86/mm/fault.c:1474 [inline]
> >   exc_page_fault+0x6f/0xd0 arch/x86/mm/fault.c:1527
> >   asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
>
> This is the VM_BUG_ON_MM(hpage_collapse_test_exit(mm), mm), which checks
>
> 	atomic_read(&mm->mm_users) == 0;
>
> So we have mm->mm_users == 0 while processing a page fault. Weird.

mm lifecycle... pinging Liam :)

>
> --
> Cheers,
>
> David

Cheers, Lorenzo