Re: [syzbot] [mm?] WARNING in vma_mark_detached

[Lorenzo Stoakes <ljs@kernel.org>]

On Mon, Apr 20, 2026 at 02:14:28PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    43cfbdda5af6 Merge tag 'for-linus-iommufd' of git://git.ke..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17711906580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8195c5b22e79c2cf
> dashboard link: https://syzkaller.appspot.com/bug?extid=db390288d141a1dccf96
> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14cd78ce580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=161f82d2580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/848e46852283/disk-43cfbdda.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/24283dbdc318/vmlinux-43cfbdda.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/f91b3fadd31d/bzImage-43cfbdda.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+db390288d141a1dccf96@syzkaller.appspotmail.com
>
> RDX: bbdccba4532b703b RSI: 0000200000000000 RDI: 0000000000000000
> RBP: 00007ffcde93cf30 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007fa5dec15fac R14: 00007fa5dec15fa0 R15: 00007fa5dec15fa0
>  </TASK>
> HugeTLB: unable to allocate vma specific lock

OK so this is the (sketchy) hugetlb 'VMA lock' allocation code, which in fact is
not a VMA lock in the sense of core mm, but rather a hugetlb-specific thing.

There is an alloc failiure injected to do that.

> ------------[ cut here ]------------
> !vma_is_attached(vma)
> WARNING: ./include/linux/mmap_lock.h:435 at vma_assert_attached include/linux/mmap_lock.h:435 [inline], CPU#0: syz.0.17/6011
> WARNING: ./include/linux/mmap_lock.h:435 at vma_mark_detached+0x198/0x260 include/linux/mmap_lock.h:455, CPU#0: syz.0.17/6011

But this is saying the VMA is detached, which shouldn't be the case...

From the below, we're in an mmap compatibility layer scenario, so this is
complicated:

shmat
-> mmap_region
-> shm_mmap
-> compat_vma_mmap
-> mmap_action_complete
-> do_munmap
-> vms_gather_munmap_vmas
-> vma_mark_detached

This then is a product of the VMA being in its incomplete, not-yet-initialised
state, which explains why the VMA is detached.

So I think we need a way of propagating to the mmap_action_finish() handler that
we're in a compat handler and thus the unmapping is unnecessary.

I'll come up with a patch!

Cheers, Lorenzo

> Modules linked in:
> CPU: 0 UID: 0 PID: 6011 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
> RIP: 0010:vma_assert_attached include/linux/mmap_lock.h:435 [inline]
> RIP: 0010:vma_mark_detached+0x198/0x260 include/linux/mmap_lock.h:455
> Code: 01 00 00 00 89 ee e8 57 5f a4 ff 85 ed 7e 4b e8 0e 5b a4 ff 48 89 df 5b 41 5c 41 5e 41 5f 5d e9 7e db f3 ff e8 f9 5a a4 ff 90 <0f> 0b 90 eb 95 e8 ee 5a a4 ff 90 0f 0b 90 e9 04 ff ff ff e8 e0 5a
> RSP: 0018:ffffc90003396df0 EFLAGS: 00010293
> RAX: ffffffff8220ba17 RBX: ffff8880536f8500 RCX: ffff88802baf3d80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffff8880536f8583 R09: 1ffff1100a6df0b0
> R10: dffffc0000000000 R11: ffffed100a6df0b1 R12: dffffc0000000000
> R13: ffffc90003397130 R14: ffff8880536f8580 R15: 0000000000000001
> FS:  000055555c863500(0000) GS:ffff88812522b000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b2fb63fff CR3: 00000000325d8000 CR4: 00000000003526f0
> Call Trace:
>  <TASK>
>  vms_gather_munmap_vmas+0x6ab/0x1380 mm/vma.c:1458
>  do_vmi_align_munmap+0x2b4/0x4b0 mm/vma.c:1595
>  do_vmi_munmap+0x252/0x2d0 mm/vma.c:1652
>  do_munmap+0xf9/0x170 mm/mmap.c:1067
>  mmap_action_finish mm/util.c:1422 [inline]
>  mmap_action_complete+0x480/0x590 mm/util.c:1491
>  compat_vma_mmap+0x243/0x2c0 mm/util.c:1280
>  vfs_mmap include/linux/fs.h:2072 [inline]
>  shm_mmap+0xda/0x200 ipc/shm.c:607
>  vfs_mmap include/linux/fs.h:2074 [inline]
>  mmap_file mm/internal.h:168 [inline]
>  __mmap_new_file_vma mm/vma.c:2496 [inline]
>  __mmap_new_vma mm/vma.c:2562 [inline]
>  __mmap_region mm/vma.c:2771 [inline]
>  mmap_region+0x1ab2/0x2280 mm/vma.c:2856
>  do_mmap+0xc39/0x10c0 mm/mmap.c:560
>  do_shmat+0x8d8/0xc10 ipc/shm.c:1662
>  __do_sys_shmat ipc/shm.c:1698 [inline]
>  __se_sys_shmat ipc/shm.c:1693 [inline]
>  __x64_sys_shmat+0x9c/0xf0 ipc/shm.c:1693
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fa5de99c819
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffcde93cec8 EFLAGS: 00000246 ORIG_RAX: 000000000000001e
> RAX: ffffffffffffffda RBX: 00007fa5dec15fa0 RCX: 00007fa5de99c819
> RDX: bbdccba4532b703b RSI: 0000200000000000 RDI: 0000000000000000
> RBP: 00007ffcde93cf30 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007fa5dec15fac R14: 00007fa5dec15fa0 R15: 00007fa5dec15fa0
>  </TASK>
>
>
> ---
> 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