In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix device management cmd timeout flow
In the UFS error handling flow, the host will send a device management cmd
(NOP OUT) to the device for link recovery. If this cmd times out and
clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and
return. hba->dev_cmd.complete struct is not set to NULL.
When this happens, if cmd has been completed by device, then we will call
complete() in __ufshcd_transfer_req_compl(). Because the complete struct is
allocated on the stack, the following crash will occur:
ipanic_die+0x24/0x38 [mrdump]
die+0x344/0x748
arm64_notify_die+0x44/0x104
do_debug_exception+0x104/0x1e0
el1_dbg+0x38/0x54
el1_sync_handler+0x40/0x88
el1_sync+0x8c/0x140
queued_spin_lock_slowpath+0x2e4/0x3c0
__ufshcd_transfer_req_compl+0x3b0/0x1164
ufshcd_trc_handler+0x15c/0x308
ufshcd_host_reset_and_restore+0x54/0x260
ufshcd_reset_and_restore+0x28c/0x57c
ufshcd_err_handler+0xeb8/0x1b6c
process_one_work+0x288/0x964
worker_thread+0x4bc/0xc7c
kthread+0x15c/0x264
ret_from_fork+0x10/0x30
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel availability issue in the UFS storage error-recovery path. Under a specific device-management timeout condition, the kernel can later complete a stack-allocated object and crash. The practical business impact is service interruption on affected Linux systems using this storage path, not data theft or privilege escalation based on the provided CVSS and description.
Executive priority
Handle in normal kernel patch cycles, with higher priority for shared, mobile, embedded, or appliance-like systems where local users or workloads can trigger storage recovery paths. There is no sourced evidence of active exploitation, but the failure mode is a kernel crash.
Technical view
The UFS core NOP OUT recovery command can time out while doorbell clearing fails. In that path, ufshcd_wait_for_dev_cmd() returns without nulling hba->dev_cmd.complete. If the device later completes the command, __ufshcd_transfer_req_compl() may call complete() on a stack object, causing a kernel crash.
Likely exposure
Exposure is most relevant to Linux systems running affected kernel versions or commit ranges with the UFS storage stack in use. The bundle names Linux as affected and lists 5.19 through 6.3-era versions, with some fixed stable commits referenced. Product-specific distribution backports are not provided.
Exploitation context
The CVSS vector is local, low complexity, low privilege, no user interaction, and high availability impact. The source bundle says KEV is false and provides no evidence of active exploitation. Treat this as a local denial-of-service risk until vendor advisories say otherwise.
Researcher notes
The key condition is a UFS device-management command timeout combined with failed doorbell clearing, leaving hba->dev_cmd.complete stale. The crash trace indicates use of a stack-allocated completion after return. The CVE has no CWE mapping and limited vendor-specific exposure data in the bundle.
Mitigation direction
Apply the relevant Linux stable fixes referenced for the affected kernel branch.
Check your OS or device vendor for backported kernel updates.
Prioritize systems where UFS storage support is enabled or required.
If no update is available, follow vendor guidance; no workaround is named in the sources.
Validation and detection
Inventory Linux kernel versions against the affected and fixed versions in the CVE record.
Confirm whether the UFS storage driver is present and used on candidate systems.
Review kernel crash logs for ufshcd_wait_for_dev_cmd or __ufshcd_transfer_req_compl traces.
Verify patched kernels include one of the referenced stable commits or a vendor backport.
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-53387 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.