В ядре Linux устранена следующая уязвимость:
мощность: источник питания: rt9455: приостановить работу с задержкой перед демонтажем
Поточный обработчик IRQ может поставить в очередь pwr_rdy_work,
max_charging_time_work и batt_presence_work. pwr_rdy_work и
batt_presence_work также может поставить в очередь max_charging_time_work, а
batt_presence_work может запросить себя.
rt9455_remove() отменяет max_charging_time_work раньше
batt_presence_work. Таким образом, последний может стоять в очереди
max_charging_time_work после того, как оно уже было отменено:
rt9455_remove() рабочая очередь
отменить pwr_rdy_work
отменить max_charging_time_work
batt_presence_work очереди
max_charging_time_work
отменить batt_presence_work
возвращение
Деврес освобождает rt9455_info
разыменования max_charging_time_work
rt9455_info
IRQ также остается зарегистрированным до тех пор, пока устройство не очистит его, и может поставить в очередь больше
работать после любого из вызовов отмены. Если rt9455_hw_init() не работает
после запроса IRQ зонд возвращается без отмены работы
возможно, это уже было в очереди.
Ожидающий обратный вызов может затем получить доступ
rt9455_info после его освобождения. Зарегистрируйте rt9455_cancel_all_delayed_works() через
devm_add_action_or_reset() сразу после devm_power_supply_register().
devres вызывает действие в обратном порядке регистрации, после
управляемое IRQ было освобождено до освобождения rt9455_info, поэтому
отложенные работы удаляются как в rt9455_remove(), так и в ошибке зонда
путь. Отмените pwr_rdy_work и batt_presence_work раньше
max_charging_time_work, потому что оба могут поставить последнее в очередь.
Эта проблема была обнаружена с помощью собственного инструмента статического анализа.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: quiesce delayed work before teardown The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool.
Характеристики атаки
Последствия
Строка CVSS v3.1