linux-kernel - Re: [BUG] usb: sleepable spinlock used in USB bh_worker softirq on PREEMPT

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: <a4e338f2-38dd-4c1e-b3c0-e6d18e7568fb@kzalloc.com>
Date: Tue, 12 Aug 2025 00:40:38 +0900
From: Yunseong Kim <ysk@...lloc.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-usb@...r.kernel.org, linux-rt-users@...r.kernel.org,
 gregkh@...uxfoundation.org, stern@...land.harvard.edu,
 Thomas Gleixner <tglx@...utronix.de>, Clark Williams <clrkwllms@...nel.org>,
 Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
 syzkaller@...glegroups.com
Subject: Re: [BUG] usb: sleepable spinlock used in USB bh_worker softirq on
 PREEMPT_RT

Hi Sebastian,

Thank you for your prompt reply and clarification.

On 8/11/25 6:15 오후, Sebastian Andrzej Siewior wrote:
> On 2025-08-11 00:05:49 [+0900], Yunseong Kim wrote:
>> While running a PREEMPT_RT-enabled kernel I observed a sleepable
>> spinlock (rt_spin_lock) being taken from a softirq context within
>> the USB core framework. On PREEMPT_RT, spin_lock() may sleep when
>> contended. This is unsafe in softirq context and can cause hangs or
>> deadlocks.
>>
> …
>> I believe this requires a change in the USB core framework rather than
>> just in individual drivers.
>>
>> Kernel config, full logs, and reproduction steps can be provided on
>> request.
>>
>> This bug was uncovered during my work to fixing KCOV for PREEMPT_RT awareness.
>> Link: https://lore.kernel.org/all/ee26e7b2-80dd-49b1-bca2-61e460f73c2d@kzalloc.com/t/#u
> 
> I'm confused. Is this new or this the same bug that was reported by you
> in the thread you linked?
> The kcov issue should be fixed by
> 	https://lore.kernel.org/all/20250811082745.ycJqBXMs@linutronix.de/

You are absolutely right.

While PREEMPT_RT does shift most softirq handling to the ksoftirqd process
context where sleeping locks are generally allowed, I overlooked the ironclad
rule: DO NOT SLEEP if interrupts are disabled. Even in ksoftirqd, disabling
interrupts creates an atomic context, and acquiring a sleeping lock while
irqs_disabled() is true can be disastrous in real-time environments.

The bug I reported, specifically the call stack observed where rt_spin_lock was
taken from a softirq context within the USB core framework, was a direct
consequence of this misunderstanding. This issue was uncovered during my work on
fixing KCOV for PREEMPT_RT awareness and was consistently reproducible across my
v1 through v3 patches. For reference, my v3 work can be found here:
 https://lore.kernel.org/lkml/ddd14f62-b6c9-4984-84be-6c999ea92e30@kzalloc.com/t/#u.

I have applied your patch:
 https://lore.kernel.org/all/20250811082745.ycJqBXMs@linutronix.de/

-static inline unsigned long kcov_remote_start_usb_softirq(u64 id)
+static inline void kcov_remote_start_usb_softirq(u64 id)
 {
-	unsigned long flags = 0;
-
-	if (in_serving_softirq()) {
-		local_irq_save(flags);
+	if (in_serving_softirq() && !in_hardirq())
 		kcov_remote_start_usb(id);

!in_hardirq(), I can definitely confirm that the specific call stack and the bug
I reported are no longer reproducible. Your fix has indeed addressed the
underlying issue.

>> Best Regards,
>> Yunseong Kim
> 
> Sebastian

Thank you again for your guidance and for resolving this problem!

Best Regards,
Yunseong Kim