CVE-2023-53760
Description
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue
When ufshcd_err_handler() is executed, CQ event interrupt can enter waiting for the same lock. This can happen in ufshcd_handle_mcq_cq_events() and also in ufs_mtk_mcq_intr(). The following warning message will be generated when &hwq->cq_lock is used in IRQ context with IRQ enabled. Use ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to resolve the deadlock issue.
[name:lockdep&]WARNING: inconsistent lock state [name:lockdep&]-------------------------------- [name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes: ffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at: ufshcd_mcq_poll_cqe_lock+0x30/0xe0 [name:lockdep&]{IN-HARDIRQ-W} state was registered at: lock_acquire+0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod] __handle_irq_event_percpu+0x140/0x3ec handle_irq_event+0x50/0xd8 handle_fasteoi_irq+0x148/0x2b0 generic_handle_domain_irq+0x4c/0x6c gic_handle_irq+0x58/0x134 call_on_irq_stack+0x40/0x74 do_interrupt_handler+0x84/0xe4 el1_interrupt+0x3c/0x78
Possible unsafe locking scenario: CPU0 ---- lock(&hwq->cq_lock);
lock(&hwq->cq_lock); * DEADLOCK * 2 locks held by kworker/u16:4/260:
[name:lockdep&] stack backtrace: CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S W OE 6.1.17-mainline-android14-2-g277223301adb #1 Workqueue: ufs_eh_wq_0 ufshcd_err_handler
Call trace: dump_backtrace+0x10c/0x160 show_stack+0x20/0x30 dump_stack_lvl+0x98/0xd8 dump_stack+0x20/0x60 print_usage_bug+0x584/0x76c mark_lock_irq+0x488/0x510 mark_lock+0x1ec/0x25c __lock_acquire+0x4d8/0xffc lock_acquire+0x17c/0x33c _raw_spin_lock+0x5c/0x7c ufshcd_mcq_poll_cqe_lock+0x30/0xe0 ufshcd_poll+0x68/0x1b0 ufshcd_transfer_req_compl+0x9c/0xc8 ufshcd_err_handler+0x3bc/0xea0 process_one_work+0x2f4/0x7e8 worker_thread+0x234/0x450 kthread+0x110/0x134 ret_from_fork+0x10/0x20
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A deadlock in Linux kernel's UFS MCQ driver, when the error handler contends with interrupt context for the same spinlock.
Vulnerability
In the Linux kernel's UFS (Universal Flash Storage) driver, the Multi-Circular Queue (MCQ) path contains a locking flaw. The &hwq->cq_lock is a spinlock that can be acquired in both interrupt (hard-IRQ) context (e.g., when the MCU interrupt handler ufs_mtk_mcq_intr() fires) and in task context (e.g., inside the error handler ufshcd_err_handler()). The lock's usage was not consistently disabling interrupts, leading to a potential deadlock: the error handler could be preempted by a CQ event interrupt that tries to take the same lock [1].
Exploitation
An attacker with local access who can trigger a UFS error condition (for example, by sending malformed SCSI commands or inducing a device timeout) could cause the error handler workqueue (ufs_eh_wq_0) to execute. If, during that execution, a CQ event interrupt arrives (which is normal device behavior), the interrupt handler (ufs_mtk_mcq_intr() or ufshcd_handle_mcq_cq_events()) would attempt to lock &hwq->cq_lock while the error handler already holds it. The kernel's lockdep mechanism reports this as a possible deadlock scenario, and the system would hit a warning and potentially hang [1].
Impact
A successful exploitation leads to a kernel deadlock, causing a denial of service (system hang or crash). As the issue is in the storage driver, it can also cause data corruption or loss if the device becomes unresponsive during I/O operations. The vulnerability does not require authentication beyond local access to the device.
Mitigation
The fix, introduced in Linux kernel stable commit [1], replaces the plain spin_lock() call inside ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave(), which disables local interrupts during the critical section. This prevents the interrupt handler from running on the same CPU while the error handler holds the lock, eliminating the deadlock. The patch has been applied to the mainline kernel and backported to stable branches. Users should update to a kernel containing this commit.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
22ce8c49c7b53948afc696151Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.