Re: [syzbot] [mm?] possible deadlock in lock_next_vma

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

Yup, aligns with my analysis, thanks!

I think it's just a case of parallel ioctl's not being taken into account
here.

On Tue, Jul 15, 2025 at 09:27:16AM +0800, Hillf Danton wrote:
> > Date: Mon, 14 Jul 2025 09:38:33 -0700	[thread overview]
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:    0be23810e32e Add linux-next specific files for 20250714
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15cfb0f0580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=be9e2082003f81ff
> > dashboard link: https://syzkaller.appspot.com/bug?extid=159a3ef1894076a6a6e9
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1003b18c580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11437d82580000
>
> #syz test
>
> --- x/fs/proc/task_mmu.c
> +++ y/fs/proc/task_mmu.c
> @@ -585,6 +585,7 @@ no_vma:
>  	return ERR_PTR(-ENOENT);
>  }
>
> +static DEFINE_MUTEX(query_mutex);
>  static int do_procmap_query(struct proc_maps_private *priv, void __user *uarg)
>  {
>  	struct procmap_query karg;
> @@ -620,8 +621,10 @@ static int do_procmap_query(struct proc_
>  	if (!mm || !mmget_not_zero(mm))
>  		return -ESRCH;
>
> +	mutex_lock(&query_mutex);
>  	err = query_vma_setup(priv);
>  	if (err) {
> +		mutex_unlock(&query_mutex);
>  		mmput(mm);
>  		return err;
>  	}
> @@ -712,6 +715,7 @@ static int do_procmap_query(struct proc_
>
>  	/* unlock vma or mmap_lock, and put mm_struct before copying data to user */
>  	query_vma_teardown(priv);
> +	mutex_unlock(&query_mutex);
>  	mmput(mm);
>
>  	if (karg.vma_name_size && copy_to_user(u64_to_user_ptr(karg.vma_name_addr),
> @@ -732,6 +736,7 @@ static int do_procmap_query(struct proc_
>
>  out:
>  	query_vma_teardown(priv);
> +	mutex_unlock(&query_mutex);
>  	mmput(mm);
>  	kfree(name_buf);
>  	return err;
> --