GHSA-2XVR-5MWV-W22P
Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-24 00:32In the Linux kernel, the following vulnerability has been resolved:
slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock
During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers.
But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock).
The result is a lockdep splat, and a possible deadlock:
rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus
but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl
which lock already depends on the new lock.
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock);
The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg().
Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed.
Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-53331"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T14:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nslimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl-\u003elock\n\nDuring the SSR/PDR down notification the tx_lock is taken with the\nintent to provide synchronization with active DMA transfers.\n\nBut during this period qcom_slim_ngd_down() is invoked, which ends up in\nslim_report_absent(), which takes the slim_controller lock. In multiple\nother codepaths these two locks are taken in the opposite order (i.e.\nslim_controller then tx_lock).\n\nThe result is a lockdep splat, and a possible deadlock:\n\n rprocctl/449 is trying to acquire lock:\n ffff00009793e620 (\u0026ctrl-\u003elock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus\n\n but task is already holding lock:\n ffff00009793fb50 (\u0026ctrl-\u003etx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl\n\n which lock already depends on the new lock.\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026ctrl-\u003etx_lock);\n lock(\u0026ctrl-\u003elock);\n lock(\u0026ctrl-\u003etx_lock);\n lock(\u0026ctrl-\u003elock);\n\nThe assumption is that the comment refers to the desire to not call\nqcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction.\nBut any such transaction is initiated and completed within a single\nqcom_slim_ngd_xfer_msg().\n\nPrior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn\ndown, all child devices are notified that the slimbus is gone and the\nchild devices are removed.\n\nStop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the\ndeadlock.",
"id": "GHSA-2xvr-5mwv-w22p",
"modified": "2026-07-24T00:32:31Z",
"published": "2026-07-01T15:35:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d1561537237c6cc1db76155183d8bbdac2339f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55f2ea9ff83cc27a85526b14bc9b32f96a08d6ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9708eb50fd7343145b422be852f890212155d845"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f0d45d509b434c54da10e01f4ef8086e4583401"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aad4337a21b9ad3ae8d668fa8678d05e26ecbaa8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d54a221b0f3cd9e1f03f18104be34e02a8258fae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc4d5c57e012c2c669793deb1515a57bbc6bf5dd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.