LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53760: scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue

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

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel storage-driver deadlock in the UFS multi-circular queue path. Under error handling and interrupt timing, the kernel can try to take the same queue lock twice and hang that path. The available sources do not show remote exploitation, active exploitation, CVSS, or business-impact details.

Executive priority

Treat this as a targeted kernel reliability issue, not a confirmed active exploitation emergency. Prioritize patch validation where UFS-based Linux devices support business operations, because storage-driver deadlocks can still cause availability incidents.

Technical view

The issue is in UFS core MCQ locking around hwq->cq_lock. ufshcd_err_handler can run while CQ event interrupt handling also waits on the same lock, producing inconsistent hard-IRQ locking and possible deadlock. The cited fix changes polling to use IRQ-safe locking through ufshcd_mcq_poll_cqe_lock with spin_lock_irqsave.

Likely exposure

Exposure is most likely on Linux kernels in the cited affected UFS MCQ range, especially systems using UFS storage controllers. The source references Linux kernel 6.3-series metadata and specific stable commits, but it does not enumerate distributions, device models, or vendor backports.

Exploitation context

No source in the bundle reports active exploitation, public exploit code, KEV listing, or a remote attack path. The evidence describes a reliability failure triggered by kernel error-handling and interrupt context interaction, not an attacker-controlled exploit scenario.

Researcher notes

Evidence is limited to the CVE record and Linux stable commit references. The trace includes Android 14 mainline and MediaTek UFS interrupt context, but the affected product is recorded as Linux. Avoid broad product claims without vendor-specific advisories.

Mitigation direction

  • Review kernel vendor advisories for CVE-2023-53760 and UFS MCQ fixes.
  • Update to a kernel containing the cited stable commits or vendor backport.
  • Prioritize devices using UFS storage and affected 6.3-series kernels.
  • Monitor for storage hangs, lockdep warnings, or UFS error-handler stalls.
  • Do not assume non-upstream vendor kernels are fixed without backport confirmation.

Validation and detection

  • Inventory Linux kernel versions and vendor patch levels.
  • Check whether systems use UFS storage and MCQ-capable drivers.
  • Confirm whether the cited stable commits are present or backported.
  • Review kernel logs for cq_lock, ufshcd_err_handler, or lockdep deadlock warnings.
  • Map affected assets to business-critical mobile, embedded, or storage-dependent systems.
Prepared
Confidence
medium
Sources
4

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-53760 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxed975065c31c2a0372e13c19e8140b69814a98ba, ed975065c31c2a0372e13c19e8140b69814a98baunaffected
LinuxLinux6.3, 0, 6.3.3, 6.4affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.