В ядре Linux устранена следующая уязвимость:
sched/core: обработка Pick_task(), снимающая блокировку rq. Функция Pick_next_task() основного планирования прерывается, когда ->pick_task()
реализация может снять блокировку rq. Состояние выбора, полученное при входе
действует только в том случае, если блокировка удерживается непрерывно.
Как только выбор может упасть
блокировки, выбор чередования может сделать все это недействительным: однопроцессорный
быстрый путь может зафиксировать необработанный выбор, хотя ядро во время выполнения было сохранено.
освобождение и принудительное нажатие, совершенные перемежающимся выбором, искажают
перезапустил учет пропусков. Исправьте это, перезапустив весь выбор, когда выбор вернет RETRY_TASK.
после снятия блокировки: одна точка перезапуска выше вывода состояния
заменяет метки перезапуска для каждого цикла, поэтому повторная попытка выбирает состояние, зафиксированное
чередование выделений и учетных записей и сброс принудительного холостого хода, как новый
выбор бы. Need_sync и fi_before фиксируются при повторных попытках.
Срок действия часов не может быть
повторно полученный - не существует программно-упорядоченного способа определить, являются ли собственные и
Частота ядра RQ по-прежнему обновляется после снятия блокировки, как и другие
циклы запирания шкафчиков могли или не могли сделать их недействительными. При перезапуске
очистите core_lock_updated, чтобы родственный цикл повторно обновил ядро rq,
и обновить собственные часы rq, если они признаны недействительными.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: sched/core: Handle pick_task() releasing the rq lock Core scheduling's pick_next_task() breaks when a ->pick_task() implementation can release the rq lock. The selection state derived on entry is only valid while the lock is held continuously. Once a pick can drop the lock, an interleaving selection can invalidate all of it: the single-CPU fast path can commit an uncookied pick although the core went cookied during the release, and forceidle committed by the interleaving selection skews the restarted pass's accounting. Fix it by restarting the whole selection when a pick returns RETRY_TASK after releasing the lock: a single restart point above the state derivation replaces the per-loop restart labels, so a retry picks up state committed by interleaving selections and accounts and resets forceidle like a fresh selection would. need_sync and fi_before latch across retries. Clock validity can't be re-derived - there is no program-ordered way to tell whether the own and core rq clocks are still updated after the lock was released, as other lockers' pin cycles may or may not have invalidated them. When restarting, clear core_clock_updated so that the sibling loop re-updates the core rq, and update the own rq clock if invalidated.
Характеристики атаки
Последствия
Строка CVSS v3.1