CVE-2026-53331

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl-&gt;lock<br /> <br /> During the SSR/PDR down notification the tx_lock is taken with the<br /> intent to provide synchronization with active DMA transfers.<br /> <br /> But during this period qcom_slim_ngd_down() is invoked, which ends up in<br /> slim_report_absent(), which takes the slim_controller lock. In multiple<br /> other codepaths these two locks are taken in the opposite order (i.e.<br /> slim_controller then tx_lock).<br /> <br /> The result is a lockdep splat, and a possible deadlock:<br /> <br /> rprocctl/449 is trying to acquire lock:<br /> ffff00009793e620 (&amp;ctrl-&gt;lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus<br /> <br /> but task is already holding lock:<br /> ffff00009793fb50 (&amp;ctrl-&gt;tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl<br /> <br /> which lock already depends on the new lock.<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> lock(&amp;ctrl-&gt;tx_lock);<br /> lock(&amp;ctrl-&gt;lock);<br /> <br /> The assumption is that the comment refers to the desire to not call<br /> qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction.<br /> But any such transaction is initiated and completed within a single<br /> qcom_slim_ngd_xfer_msg().<br /> <br /> Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn<br /> down, all child devices are notified that the slimbus is gone and the<br /> child devices are removed.<br /> <br /> Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the<br /> deadlock.