CVE-2026-45907 in Linux
Сводка
по VulDB • 03.06.2026
В ядре Linux устранена следующая уязвимость:
net/mlx5e: Исправлены взаимные блокировки (deadlocks) между блокировками экземпляров devlink и netdev
В упомянутом коммите «Fixes» различные рабочие задачи, инициирующие восстановление от репортера здоровья devlink, были изменены для использования функции `netdev_trylock` с целью защиты от одновременного разрыва каналов, которые восстанавливаются. Однако это привело к побочному эффекту в виде потенциальных взаимных блокировок из-за неправильного порядка захвата блокировок.
Правильный порядок блокировок описывается потоком инициализации: probe_one -> mlx5_init_one (захватывает devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (захватывает rtnl lock) -> register_netdevice (захватывает netdev lock) => devlink lock -> rtnl lock -> netdev lock.
Однако в текущем потоке восстановления порядок неверен: mlx5e_tx_err_cqe_work (захватывает netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (захватывает devlink lock => ошибка!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover
Та же самая паттерн существует в: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout
Исправьте это, переместив вызовы `netdev_trylock` из обработчиков рабочих задач ниже по стеку вызовов — непосредственно в соответствующие функции восстановления, где они фактически необходимы.
If you want to get best quality of vulnerability data, you may have to visit VulDB.