CVE-2026-53331

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 qcomslimngddown() is invoked, which ends up in slimreportabsent(), which takes the slimcontroller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slimcontroller then txlock).

The result is a lockdep splat, and a possible deadlock:

rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slimreportabsent (drivers/slimbus/core.c:322) slimbus

but task is already holding lock: ffff00009793fb50 (&ctrl->txlock){+.+.}-{4:4}, at: qcomslimngdssrpdrnotify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slimqcomngd_ctrl

which lock already depends on the new lock.

Possible unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----

lock(&ctrl->txlock); lock(&ctrl->lock); lock(&ctrl->txlock); lock(&ctrl->lock);

The assumption is that the comment refers to the desire to not call qcomslimngdexitdma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcomslimngdxfermsg().

Prior to calling qcomslimngdexitdma() 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 txlock in qcomslimngdssrpdrnotify() to avoid the deadlock.