linux-kernel - Re: [syzbot] [net?] possible deadlock in vm_insert

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241228110207.593-1-hdanton@sina.com>
Date: Sat, 28 Dec 2024 19:01:51 +0800
From: Hillf Danton <hdanton@...a.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
	syzbot <syzbot+11701838dd42428ab7b3@...kaller.appspotmail.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	edumazet@...gle.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [net?] possible deadlock in vm_insert_page

On Sat, 28 Dec 2024 01:52:28 -0800 Boqun Feng <boqun.feng@...il.com>
> On Fri, Dec 27, 2024 at 06:03:45PM -0800, Suren Baghdasaryan wrote:
> > On Fri, Dec 27, 2024 at 4:19 PM Hillf Danton <hdanton@...a.com> wrote:
> > > On Fri, 27 Dec 2024 04:59:22 -0800
> > > >
> > > >        CPU0                    CPU1
> > > >        ----                    ----
> > > >   lock(&po->pg_vec_lock);
> > > >                                lock(&mm->mmap_lock);
> > > >                                lock(&po->pg_vec_lock);
> > > >   lock(&vma->vm_lock->lock);
> > > >
> > > >  *** DEADLOCK ***
> > > >
> > > > 2 locks held by syz.8.396/8273:
> > > >  #0: ffff0000d6a2cc10 (&mm->mmap_lock){++++}-{4:4}, at: mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
> > > >  #0: ffff0000d6a2cc10 (&mm->mmap_lock){++++}-{4:4}, at: vm_mmap_pgoff+0x154/0x38c mm/util.c:578
> > > >  #1: ffff0000d4aa2868 (&po->pg_vec_lock){+.+.}-{4:4}, at: packet_mmap+0x9c/0x4c8 net/packet/af_packet.c:4650
> > > >
> > > Given &mm->mmap_lock and &po->pg_vec_lock in same locking order on both sides,
> > > this deadlock report is bogus. Due to lockdep glitch?
> 
> What do you mean by "both sides"? Note that, here is the report saying

CPU0/1 in the lockdep diagram above.

> the locks that are already held by the current task, and that current
> task is going to acquire &vma->vm_lock->lock, so lockdep finds new
> dependency:

Note the current task acquires &po->pg_vec_lock after taking &mm->mmap_lock,
and it is the &mm->mmap_lock (ignored by lockdep?) that makes the report
look bogus.
> 
> 	&po->pg_vec_lock --> &vma->vm_lock->lock
> 
> and there will be a circular dependency because (see above) lockdep
> recorded a dependency chain that:
> 
> 	&vma->vm_lock->lock --> ... --> &po->pg_vec_lock