linux-kernel - Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected (2)

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] [day] [month] [year] [list]

Message-ID: <20200910071523.GF7922@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net>
Date:   Thu, 10 Sep 2020 15:15:23 +0800
From:   Boqun Feng <boqun.feng@...il.com>
To:     syzbot <syzbot+22e87cdf94021b984aa6@...kaller.appspotmail.com>
Cc:     bfields@...ldses.org, jlayton@...nel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, peterz@...radead.org,
        syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk,
        will@...nel.org
Subject: Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected (2)

Thanks!

On Wed, Sep 09, 2020 at 06:19:06AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit f08e3888574d490b31481eef6d84c61bedba7a47
> Author: Boqun Feng <boqun.feng@...il.com>
> Date:   Fri Aug 7 07:42:30 2020 +0000
> 
>     lockdep: Fix recursive read lock related safe->unsafe detection
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13034be1900000
> start commit:   dff9f829 Add linux-next specific files for 20200908
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=10834be1900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=17034be1900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=37b3426c77bda44c
> dashboard link: https://syzkaller.appspot.com/bug?extid=22e87cdf94021b984aa6
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=108b740d900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12daa9ed900000
> 
> Reported-by: syzbot+22e87cdf94021b984aa6@...kaller.appspotmail.com
> Fixes: f08e3888574d ("lockdep: Fix recursive read lock related safe->unsafe detection")
> 

This is another deadlock possibility detected by lockdep's new detection
algorithm.

The deadlock happens as follow:

	CPU 0				CPU 1			CPU 2
	read_lock(&fown->lock);
					spin_lock_irqsave(&dev->event_lock, ...)
								write_lock_irq(&filp->f_owner.lock); // wait for the lock
					read_lock(&fown-lock); // have to wait until the writer release
							       // due to the fairness
	<interrupted>
	spin_lock_irqsave(&dev->event_lock); // wait for the lock

The lock dependency on CPU 1 happens if there exists a call sequence:

	input_inject_event():
	  spin_lock_irqsave(&dev->event_lock,...);
	  input_handle_event():
	    input_pass_values():
	      input_to_handler():
	        handler->event(): // evdev_event()
	          evdev_pass_values():
	            spin_lock(&client->buffer_lock);
	            __pass_event():
	              kill_fasync():
	                kill_fasync_rcu():
	                  read_lock(&fa->fa_lock);
	                  send_sigio():
	                    read_lock(&fown->lock);

A possible fix would be replacing the read_lock() with read_lock_irq()
or read_lock_irqsave().

Regards,
Boqun

> For information about bisection process see: https://goo.gl/tpsmEJ#bisection