CVE-2026-53331
NieznaneStreszczenie
W sterowniku slimbus dla układów Qualcomm (qcom-ngd-ctrl) wykryto potencjalny zakleszczający się blokadę (deadlock) spowodowaną odwrotną kolejnością blokowania tx_lock i ctrl->lock. Podczas powiadomienia o SSR/PDR down, blokada tx_lock jest przechwytywana, a następnie wywoływana jest funkcja slim_report_absent(), która próbuje przechwycić ctrl->lock, co prowadzi do odwrotnej kolejności blokad i możliwego zakleszczenia.
Ocena ryzyka
Zakleszczenie może spowodować zawieszenie się systemu lub awarię sterownika slimbus, co wpływa na działanie urządzeń komunikujących się przez to złącze (np. audio, czujniki). Atakujący lokalny może wykorzystać tę podatność do wywołania odmowy usługi (DoS).
Rekomendacja
Należy natychmiast zaktualizować jądro Linuksa do wersji zawierającej poprawkę usuwającą blokadę tx_lock w funkcji qcom_slim_ngd_ssr_pdr_notify(). Zaleca się monitorowanie dystrybucji pod kątem wydania łatki.
Oryginalny opis (angielski, źródło NVD)
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.