Katalog CVE

CVE-2026-74331

Niskie ryzyko· EPSS 9%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.19%

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

Streszczenie

W jądrze Linux w module firmware_loader występuje zakleszczenie spowodowane rekurencyjnym blokowaniem w funkcji device_cache_fw_images(). Podczas przygotowania do zawieszenia lub hibernacji, fw_pm_notify() wywołuje tę funkcję, która trzyma fw_lock podczas iteracji po urządzeniach. Jeśli alokacja pamięci dla asynchronicznego zadania się nie powiedzie, zadanie jest wykonywane synchronicznie, co prowadzi do ponownego zażądania fw_lock i zakleszczenia.

Ocena ryzyka

Zakleszczenie może wystąpić podczas zawieszenia lub hibernacji systemu, co może uniemożliwić poprawne przejście w stan uśpienia lub spowodować zawieszenie systemu.

Rekomendacja

Zaleca się zastosowanie poprawki jądra, która zwalnia fw_lock przed iteracją po urządzeniach, aby uniknąć rekurencyjnego blokowania.

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: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.

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