The issue causes a self‑deadlock in the qcom_cpucp mailbox IRQ handler when PREEMPT_RT is enabled. While holding chan->lock, the handler calls mbox_chan_received_data() which eventually calls mbox_send_message() that attempts to re‑acquire the same lock. The rtmutex detects this re‑entrant acquisition and blocks the thread, leaving it permanently in the D state and preventing the IRQ handler from completing. This state can stall the kernel or the affected mailbox channel, effectively denying services that rely on that communication path.

All Linux kernel builds that include the qcom_cpucp mailbox driver before the patch commit. The problem manifests on platforms where PREEMPT_RT is enabled and the 'irq/N-apss_cpucp_mbox' channel is active.

Based on the description, it is inferred that remote exploitation would require physical or firmware-level control to manipulate this interrupt, making external attacks unlikely. The deadlock is triggered by a hardware interrupt and requires the corresponding IRQ to fire. Remote exploitation would thus need access to the hardware or firmware level. The EPSS score is below 1% and the vulnerability is not listed in the CISA KEV catalog, indicating a low probability of widespread exploitation. Nonetheless, once triggered, the deadlock can lead to a local denial‑of‑service as the kernel thread remains stuck indefinitely.