В ядре Linux устранена следующая уязвимость:
net: usb: aqc111: не выполнять PM внутри обратного вызова приостановки
syzbot сообщает: «Задача зависла в rpm_resume»
Это вызвано вызовом aqc111_suspend
вариант PM его процедуры write_cmd. Упрощенная трассировка вызовов выглядит так:
об/мин_suspend()
usb_suspend_both() — здесь udev->dev.power.runtime_status == RPM_SUSPENDING
aqc111_suspend() — вызывается для интерфейса USB-устройства
aqc111_write32_cmd()
usb_autopm_get_interface()
pm_runtime_resume_and_get()
rpm_resume() — здесь мы вызываем rpm_resume() у нашего родителя.
rpm_resume() — Здесь мы ждем изменения статуса, которого никогда не произойдет. На этом этапе мы блокируем другую задачу, которая содержит
rtnl_lock и блокирует весь сетевой стек.
Исправьте это, заменив вызовы write_cmd их вариантами _nopm.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports "task hung in rpm_resume" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants