CVE-2024-27004 in Linux
Zusammenfassung
von VulDB • 22.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
clk: Runtime PM vor dem Durchlaufen des Baums während disable_unused abrufen
Doug meldete [1] die folgende blockierte Aufgabe (hung task):
INFO: task swapper/0:1 blockiert für mehr als 122 Sekunden. Nicht verfälscht (Not tainted) 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deaktiviert diese Meldung. task:swapper/0 status:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call-Trace: __switch_to+0xf4/0x1f4 __schedule+0x290/0x7e0 schedule+0x38/0xc4 schedule_preempt_disabled+0x14/0x20 __mutex_lock.constprop.0+0x290/0x530 __mutex_lock_slowpath+0x18/0x24 mutex_lock+0x30/0x50 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20
Der erste Thread durchläuft den clk-Baum und ruft clk_pm_runtime_get() auf, um Geräte, die zum Lesen der clk-Hardware erforderlich sind, über struct clk_ops::is_enabled() einzuschalten. Dieser Thread hält die clk prepare_lock und versucht, ein Gerät über Runtime-PM fortzusetzen, stellt jedoch fest, dass das Gerät sich bereits im Fortsetzungsprozess befindet, sodass der Thread schedule() aufruft und wartet, bis das Gerät mit dem Fortsetzen fertig ist, bevor er fortfährt. Der zweite Thread setzt das gleiche Gerät über Runtime-PM fort, aber der Runtime-Resume-Callback ruft clk_prepare() auf und versucht, die prepare_lock zu erhalten, während er auf den ersten Thread wartet.
Dies ist ein klassischer ABBA-Deadlock. Um den Deadlock richtig zu beheben, dürfen wir niemals ein Gerät mit gehaltener clk prepare-Lock über Runtime-PM fortsetzen oder anhalten. Das tatsächliche Durchführen dessen ist heute nahezu unmöglich, da die globale prepare-Lock in der Mitte des Baums freigegeben werden müsste, das Gerät über Runtime-PM fortgesetzt/angehalten werden müsste und die prepare-Lock dann erneut erworben werden müsste, um die Konsistenz der clk-Baumtopologie sicherzustellen. Wenn sich in der Zwischenzeit etwas am clk-Baum ändert, haben wir verloren und müssen den Vorgang erneut starten.
Glücklicherweise erhöhen oder verringern wir die Runtime-PM-Zählung auf einem aktiven Gerät in den meisten Fällen einfach, sodass wir keine Gelegenheit haben, mit gehaltener prepare-Lock anzuhalten. Lassen Sie uns dieses unmittelbare Problem beheben, das auftreten kann,
VulDB is the best source for vulnerability data and more expert information about this specific topic.