В ядре Linux устранена следующая уязвимость:
OPP: исправлена гонка между добавлением OPP и поиском. Между dev_pm_opp_add_dynamic() и
dev_pm_opp_find_freq_exact():
CPU0 (добавить) CPU1 (поиск)
------------------------------- ------------------------------
_opp_add()
mutex_lock()
list_add(&new_opp->узел, голова)
mutex_unlock() _opp_table_find_key()
mutex_lock()
dev_pm_opp_get(ОПП)
kref_get()
mutex_unlock()
kref_init(&new_opp->kref)
dev_pm_opp_put()
kref_put_mutex()
Вновь добавленный OPP вставляется в список до того, как будет указан его kref.
инициализирован. Параллельный поиск может найти этот OPP и увеличить его
подсчет ссылок, пока он еще не инициализирован, что приводит к подсчету ссылок
коррупция и потенциальное преждевременное освобождение.
Исправьте это, инициализировав ->kref и ->opp_table перед созданием OPP.
видимый через list_add(). Это гарантирует, что при любом одновременном поиске будет наблюдаться
полностью инициализированный объект.
[Виреш: Обновлен журнал коммитов]
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: OPP: Fix race between OPP addition and lookup A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact(): CPU0 (add) CPU1 (lookup) ------------------------------- ------------------------------ _opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get() mutex_unlock() kref_init(&new_opp->kref) dev_pm_opp_put() kref_put_mutex() The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free. Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object. [ Viresh: Updated commit log ]
Характеристики атаки
Последствия
Строка CVSS v3.1