CVE-2023-53760
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-08

Last updated on: 2025-12-08

Assigner: kernel.org

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 <snip> Possible unsafe locking scenario: CPU0 ---- lock(&hwq->cq_lock); <Interrupt> 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
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-08
Last Modified
2025-12-08
Generated
2026-05-07
AI Q&A
2025-12-08
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.1.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock issue in the Linux kernel's UFS (Universal Flash Storage) subsystem. Specifically, when the ufshcd_err_handler() function is executed, an interrupt related to the completion queue (CQ) event can attempt to acquire the same lock (&hwq->cq_lock) that is already held, causing a deadlock. The problem arises because the lock is used improperly in IRQ context with IRQs enabled, leading to inconsistent lock states and a potential system hang. The fix involves using a polling lock function (ufshcd_mcq_poll_cqe_lock) with spin_lock_irqsave instead of spin_lock to avoid this deadlock.


How can this vulnerability impact me? :

This vulnerability can cause a deadlock in the Linux kernel's UFS driver, potentially leading to system hangs or freezes when the affected lock is contended during interrupt handling. This can degrade system stability and reliability, possibly requiring a reboot to recover from the deadlock state.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring the kernel logs for specific warning messages related to lockdep inconsistent lock states and deadlocks involving &hwq->cq_lock. You can use the command 'dmesg | grep -i lockdep' or 'journalctl -k | grep -i lockdep' to look for warnings such as 'WARNING: inconsistent lock state' and messages indicating deadlocks in ufshcd_mcq_poll_cqe_lock or ufshcd_err_handler. These messages indicate the presence of the deadlock issue described.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this deadlock issue in the UFS host controller driver (ufshcd) has been fixed. The fix involves using ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to avoid the deadlock. Until an update is applied, monitoring for the warning messages and avoiding workloads that trigger the ufshcd_err_handler may reduce the risk of deadlocks.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart