Description
In 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.
Published: 2026-07-01
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In the Linux kernel, a lock ordering issue was identified in the qcom-ngd slimbus controller. The code path that handles SSR/PDR down notifications acquires tx_lock before the controller lock, while other paths acquire the controller lock before tx_lock. This inversion leads to a lockdep warning and a potential deadlock, which can stall kernel threads and cause system unresponsiveness. The flaw results in a denial‑of‑service scenario rather than direct compromise of confidentiality or integrity.

Affected Systems

Affected systems are any Linux kernel that includes the slimbus subsystem with the qcom-ngd driver before the fix. The vulnerability is present in all kernel versions that contain the qcom_ngd controller code unchanged from the original state, regardless of specific build or distribution. Upstream kernels before the commit that removed the tx_lock acquisition in qcom_slim_ngd_ssr_pdr_notify() remain affected.

Risk and Exploitability

The CVSS score was not disclosed and EPSS data is unavailable. The vulnerability is not listed in CISA's KEV catalog. Based on the description, exploiting the flaw would require triggering a SSR/PDR down notification while DMA activity is active, a condition that is usually limited to privileged kernel code or malicious device drivers. The risk, therefore, appears to be confined to a local attacker with kernel privileges, affecting system stability. The lockdep warning suggests that the deadlock could happen during normal operation if the lock ordering conflict occurs, implying that a privileged or insider attacker might be able to induce service disruption, although no direct evidence of exploitation is provided.

Generated by OpenCVE AI on July 1, 2026 at 19:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel update that removes the tx_lock acquisition in qcom_slim_ngd_ssr_pdr_notify().
  • Restart the system so the updated kernel and driver take effect.
  • If the kernel upgrade cannot be performed, blacklist or unload the qcom_ngd slimbus driver until the patched kernel is available.

Generated by OpenCVE AI on July 1, 2026 at 19:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 01 Jul 2026 20:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-663

Wed, 01 Jul 2026 13:45:00 +0000

Type Values Removed Values Added
Description In 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.
Title slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-07-01T13:32:15.733Z

Reserved: 2026-06-09T07:44:35.398Z

Link: CVE-2026-53331

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-07-01T20:00:06Z

Weaknesses
  • CWE-663

    Use of a Non-reentrant Function in a Concurrent Context