linux-kernel - Re: possible deadlock in _snd_pcm_stream_lock

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: <20200910045009.GE7922@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net>
Date:   Thu, 10 Sep 2020 12:50:09 +0800
From:   Boqun Feng <boqun.feng@...il.com>
To:     syzbot <syzbot+561a74f84100162990b2@...kaller.appspotmail.com>
Cc:     alsa-devel-owner@...a-project.org, alsa-devel@...a-project.org,
        arnd@...db.de, baolin.wang@...aro.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        paulhsia@...omium.org, perex@...ex.cz, peterz@...radead.org,
        syzkaller-bugs@...glegroups.com, tiwai@...e.com, tiwai@...e.de,
        will@...nel.org
Subject: Re: possible deadlock in _snd_pcm_stream_lock_irqsave

Thanks for reporting.

On Wed, Sep 09, 2020 at 10:33:04AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit e918188611f073063415f40fae568fa4d86d9044
> Author: Boqun Feng <boqun.feng@...il.com>
> Date:   Fri Aug 7 07:42:20 2020 +0000
> 
>     locking: More accurate annotations for read_lock()
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=112dc243900000
> start commit:   dff9f829 Add linux-next specific files for 20200908
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=132dc243900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=152dc243900000

>From what I see in the output, probably this is the new deadlock
possibility we find with lockdep, basically if we have:

	CPU 0:					CPU 1:
	read_lock(snd_card::ctl_file_rwlock);
						<irq disabled>
						spin_lock(snd_pcm_group::lock);
						read_lock(snd_card::ctl_file_rwlock);
	<interrupted by softirq>
	spin_lock(snd_pcm_group::lock);

, because the read_lock() on CPU 1 will be a fair read lock(IOW, not a
recursive reader). And if there is a third CPU is also waiting for the
write_lock(), CPU 1 cannot get the read_lock() due to the fairness:

	CPU 0:					CPU 1:					CPU 2:
	read_lock(snd_card::ctl_file_rwlock);
						<irq disabled>
						spin_lock(snd_pcm_group::lock);
											write_lock(snd_card::ctl_file_rwlock);
						read_lock(snd_card::ctl_file_rwlock); // fair read lock, can only get the lock if CPU 2 get its lock
	<interrupted by softirq>
	spin_lock(snd_pcm_group::lock);

That said, I'm still looking into the code to find whether there is a
lock combination of CPU 1. Given I'm not familiar with sound subsystem,
I will appreciate any help on finding the lock pattern on CPU 1 ;-)

Regards,
Boqun

> kernel config:  https://syzkaller.appspot.com/x/.config?x=37b3426c77bda44c
> dashboard link: https://syzkaller.appspot.com/bug?extid=561a74f84100162990b2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1209e245900000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=154b15ed900000
> 
> Reported-by: syzbot+561a74f84100162990b2@...kaller.appspotmail.com
> Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection