linux-kernel - Re: [syzbot] [sound?] possible deadlock in __snd_pcm_lib

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: <20250905030430.6482-1-hdanton@sina.com>
Date: Fri,  5 Sep 2025 11:04:29 +0800
From: Hillf Danton <hdanton@...a.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: syzbot <syzbot+10b4363fb0f46527f3f3@...kaller.appspotmail.com>,
	Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [sound?] possible deadlock in __snd_pcm_lib_xfer (2)

On Thu, 4 Sep 2025 08:12:45 +0200 Sebastian Andrzej Siewior wrote:
> On 2025-09-04 09:05:28 [+0800], Hillf Danton wrote:
> > On Wed, 3 Sep 2025 16:59:05 +0200 Sebastian Andrzej Siewior wrote:
> > > On 2025-08-30 14:56:37 [+0800], Hillf Danton wrote:
> > > > > syz.0.46/6843 is trying to acquire lock:
> > > > > ffff8880b8823d90 ((softirq_ctrl.lock)){+.+.}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:44 [inline]
> > > > > ffff8880b8823d90 ((softirq_ctrl.lock)){+.+.}-{3:3}, at: __local_bh_disable_ip+0x264/0x400 kernel/softirq.c:168
> > > > > 
> > > > Given softirq_ctrl is percpu, this report is false positive.
> > > 
> > > No. This can happen on a single CPU.
> > > 
> > But the single CPU theory fails to explain the deadlock reported.
> > 
> > > > >  Possible unsafe locking scenario:
> > > > > 
> > > > >        CPU0                    CPU1
> > > > >        ----                    ----
>                Thead0                  Thread1
> 	       ------                  -------c
> > > > >   lock(&group->lock#2);
>            preempt to ->
> > > > >                                lock((softirq_ctrl.lock));
> > > > >                                lock(&group->lock#2);
>                                        <- preempt to
> > > > >   lock((softirq_ctrl.lock));
> > > > > 
> > > > >  *** DEADLOCK ***
>                now nobody makes progress
> 
Because of the absense of the deadlock detecting mechanism in timer, see
lock_map_acquire() in call_timer_fn() for detail, hrtimer is unable to
detect deadlock like the reported one.

	CPU0			CPU1
	----			----
	lock A			hrtimer B callback
	cancel hrtimer B	lock A

On the other hand softirq_ctrl plays such a detecting role in accident, but
they are two entirely different things.