Re: [syzbot] [mm?] WARNING: lock held when returning to user space in lock_next_vma

[Suren Baghdasaryan <surenb@google.com>]

On Wed, Jul 9, 2025 at 3:26 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 7/9/25 00:19, Suren Baghdasaryan wrote:
> > On Tue, Jul 8, 2025 at 10:52 AM syzbot
> > <syzbot+80011ad33eec39e6ce42@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following issue on:
> >>
> >> HEAD commit:    26ffb3d6f02c Add linux-next specific files for 20250704
> >> git tree:       linux-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1719df70580000
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=1e4f88512ae53408
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=80011ad33eec39e6ce42
> >> compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> >> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1124abd4580000
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1099df70580000
> >>
> >> Downloadable assets:
> >> disk image: https://storage.googleapis.com/syzbot-assets/fd5569903143/disk-26ffb3d6.raw.xz
> >> vmlinux: https://storage.googleapis.com/syzbot-assets/1b0c9505c543/vmlinux-26ffb3d6.xz
> >> kernel image: https://storage.googleapis.com/syzbot-assets/9d864c72bed1/bzImage-26ffb3d6.xz
> >>
> >> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >> Reported-by: syzbot+80011ad33eec39e6ce42@syzkaller.appspotmail.com
> >>
> >> ================================================
> >> WARNING: lock held when returning to user space!
> >> 6.16.0-rc4-next-20250704-syzkaller #0 Not tainted
> >> ------------------------------------------------
> >> syz.0.22/6068 is leaving the kernel with locks still held!
> >> 1 lock held by syz.0.22/6068:
> >>  #0: ffff8880792a3588 (vm_lock){++++}-{0:0}, at: lock_next_vma+0x146/0xdc0 mm/mmap_lock.c:220
> >
> > Hmm. I must be missing an unlock_vma() somewhere but I don't see it
> > yet. Will try the reproducer.
>
> I don't see it either. I don't also see v6 being substantially different.
> Hopefully this (and the other report) was some consequence of the kmalloc()
> under rcu that v5 had. Maybe it can lead to sleep and when it wake ups it
> doesn't restore the rcu lock section?

I'm not sure. The report says that vm_lock is being held, so that does
not look like an rcu-related issue. I'll try the reproducer with v6 to
see if something fails.

>
> The unhandled vma_start_read_locked() return value I pointed out could play
> a role too (in the other report) but I guess only if syzbot would be able to
> saturate the refcount (I doubt?).

Yes, I should handle that by falling back to mmap_lock, however I
agree this would be highly unlikely.