CVE-2026-90193: mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler
In the Linux kernel, the following vulnerability has been resolved:
mailbox: qcom-cpucp: fix PREEMPTRT self-deadlock in IRQ handler
qcomcpucpmboxirqfn() calls mboxchanreceiveddata() while holding chan->lock. Under PREEMPTRT, spinlockirqsave() is converted to an rtspinlock (rtmutex-based), which tracks ownership and can sleep.
The callback chain triggered by mboxchanreceiveddata() eventually reaches mailboxclearchannel() -> mboxsendmessage() -> addtorbuf(), which attempts to re-acquire the same chan->lock. Since rtmutex detects the re-entrant lock attempt by the same owner, the thread blocks waiting for a lock it already holds, causing a permanent deadlock.
This deadlock manifests as 'irq/N-apsscpucpmbox' stuck in D state with the following call trace: rtspinlock -> mboxsendmessage -> mailboxclearchannel -> scmirxcallback -> mboxchanreceiveddata [<- held chan->lock here]
Fix by saving chan->cl locally and clearing the HW interrupt register inside the lock, then invoking mboxchanreceiveddata() after releasing the lock. This preserves the mutual exclusion for chan->cl access while avoiding the lock re-entrancy that causes the PREEMPTRT deadlock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In qcom_cpucp_mbox_irq_fn(), save chan->cl locally and clear the hardware interrupt register while holding chan->lock, then invoke mbox_chan_received_data() only after releasing chan->lock to avoid PREEMPT_RT lock re-entrancy.
Event History
Frequently Asked Questions
Which systems are exposed to this deadlock?
The issue affects Linux kernel systems using the qcom-cpucp mailbox IRQ path with PREEMPT_RT enabled. The deadlock requires the receive callback path to send a mailbox message that re-acquires chan->lock.
What does successful triggering look like in production?
The mailbox IRQ thread can become permanently blocked in D state, reported as irq/N-apss_cpucp_mbox. A relevant call trace includes rt_spin_lock, mbox_send_message, mailbox_clear_channel, scmi_rx_callback, and mbox_chan_received_data while chan->lock is already held.
What changes with the fix?
The fix clears the hardware interrupt register while holding the channel lock, but defers mbox_chan_received_data() until after releasing it. This prevents the callback chain from attempting to re-acquire the same rtmutex-backed lock.