SecvalisbySYSDEVOPS.EU
Katalog CVE
EnglishPolski

CVE-2026-53331

ŚrednieCVSS 5.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.12%

Percentyl 2 - wyżej niż 2% wszystkich znanych CVE

Streszczenie

W sterowniku slimbus dla układów Qualcomm (qcom-ngd-ctrl) wykryto potencjalny zakleszczenie (deadlock) spowodowane odwrotną kolejnością blokowania dwóch muteksów: tx_lock i ctrl->lock. Podczas procedury SSR/PDR down, blokada tx_lock jest przechwytywana przed ctrl->lock, podczas gdy w innych ścieżkach kodu kolejność jest odwrotna, co prowadzi do sytuacji ABBA i możliwego zawieszenia systemu.

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 łącze (np. audio, czujniki). Atakujący lokalny może wykorzystać tę podatność do wywołania odmowy usługi (DoS) poprzez celowe wywołanie procedury SSR/PDR.

Rekomendacja

Należy niezwłocznie zaktualizować jądro Linuksa do wersji zawierającej poprawkę usuwającą zbędne blokowanie tx_lock w funkcji qcom_slim_ngd_ssr_pdr_notify(). Zaleca się śledzenie biuletynów bezpieczeństwa dystrybucji i zastosowanie odpowiedniego łatania.

Inne podatności w Linux kernel

Zobacz wszystkie
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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS