PT-2026-54799 · Linux · Linux
Published
2026-07-01
·
Updated
2026-07-01
·
CVE-2026-53331
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux