CVE-2026-53331
Received Received - Intake

Deadlock Risk in Linux Kernel Slimbus Controller

Publication date: 2026-07-01

Last updated on: 2026-07-01

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-01
Last Modified
2026-07-01
Generated
2026-07-01
AI Q&A
2026-07-01
EPSS Evaluated
N/A
NVD
CVE-2026-53331
EUVD
EUVD-2026-40965

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
qualcomm qcom_ngd_ctrl *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability involves a potential deadlock in the Linux kernel's slimbus driver, specifically in the qcom-ngd-ctrl component. The issue arises because two locks, tx_lock and slim_controller lock, are taken in different orders in different code paths during the SSR/PDR down notification process. This inconsistent locking order can cause a lockdep splat and a possible deadlock scenario where two CPUs wait indefinitely for each other's locks.

The problem occurs when tx_lock is taken to synchronize active DMA transfers, but during this period, qcom_slim_ngd_down() is called, which takes the slim_controller lock. In other code paths, the locks are taken in the opposite order, leading to a circular dependency and deadlock.

The fix involved stopping the taking of tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid this deadlock.

Impact Analysis

This vulnerability can cause a deadlock in the Linux kernel's slimbus driver, which may lead to system hangs or freezes during certain hardware or software events involving Qualcomm NGD controllers.

Such deadlocks can impact system stability and availability, potentially causing disruptions in device operation or requiring a system reboot to recover.

Mitigation Strategies

To mitigate this vulnerability, the key step is to apply the patch or update that stops taking the tx_lock in the qcom_slim_ngd_ssr_pdr_notify() function to avoid the deadlock.

This involves updating the Linux kernel to a version where this issue is resolved, ensuring that the slimbus driver code no longer takes the tx_lock during the SSR/PDR down notification.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53331. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart