Bug 2414519 (CVE-2025-40142)

Summary: CVE-2025-40142 kernel: ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel’s Advanced Linux Sound Architecture PCM subsystem when built with the PREEMPT_RT (real-time) configuration. In snd_pcm_group_lock_irq(), the code uses spin_lock_irq() to acquire a spinlock and disable interrupts. However, on PREEMPT_RT systems, softirqs (e.g., TIMER_SOFTIRQ) remain preemptible, so a timer softirq may be raised on the same CPU during the lock. This interacts badly with softirq_ctrl.lock (a per-CPU lock used by local_bh_disable()), potentially causing a deadlock.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-11-12 11:05:17 UTC
In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT

snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts
via spin_lock_irq(). This also implicitly disables the handling of
softirqs such as TIMER_SOFTIRQ.
On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not
disable them. That means a timer can be invoked during spin_lock_irq()
on the same CPU. Due to synchronisations reasons local_bh_disable() has
a per-CPU lock named softirq_ctrl.lock which synchronizes individual
softirq against each other.
syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is
acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This
is a possible deadlock.

The softirq_ctrl.lock can not be made part of spin_lock_irq() as this
would lead to too much synchronisation against individual threads on the
system. To avoid the possible deadlock, softirqs must be manually
disabled before the lock is acquired.

Disable softirqs before the lock is acquired on PREEMPT_RT.