В ядре Linux устранена следующая уязвимость:
Firmware_loader: исправлена рекурсивная блокировка в device_cache_fw_images(). В питании загрузчика прошивки может возникнуть взаимоблокировка рекурсивной блокировки
обработчик уведомлений управления. Во время приостановки работы системы или подготовки к гибернации вызывается fw_pm_notify().
device_cache_fw_images().
Эта функция получает fw_lock для установки
состояние кэша прошивки в FW_LOADER_START_CACHE, а затем перебирает все
устройства, использующие dpm_for_each_dev(), сохраняя при этом блокировку. Для каждого устройства dev_cache_fw_image() планирует асинхронную работу по кэшированию.
прошивка. Если выделение памяти для асинхронной рабочей записи завершается неудачей (например, в
условия нехватки памяти), async_schedule_node_domain() возвращается к
синхронное выполнение рабочей функции в текущем потоке.
Путь синхронного выполнения (__async_dev_cache_fw_image() ->
cache_firmware() -> request_firmware() -> Assign_fw()) пытается получить
fw_lock еще раз. Поскольку текущий поток уже содержит fw_lock, это приводит к
в тупике рекурсивной блокировки. Исправьте это, отпустив fw_lock сразу после обновления состояния кэша.
и перед вызовом dpm_for_each_dev().
Замок нужен только для защиты
обновление состояния. Одновременные запросы прошивки будут правильно видеть
FW_LOADER_START_CACHE и использовать механизм контрейлерной связи, который
независимо защищен собственным fwc->name_lock.
Показать оригинальное описание (EN)
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.