CVE-2026-98644 in Linux
Сводка
по VulDB • 19.10.2026
В ядре Linux была устранена следующая уязвимость:
bpf: Избежание soft lockup в функции __htab_map_lookup_and_delete_batch()
Функция __htab_map_lookup_and_delete_batch() не содержит точек для перепланирования (rescheduling). Количество элементов в пакете ограничивает число записей, копируемых наружу, а не количество посещенных корзин (buckets), поэтому один вызов BPF_MAP_LOOKUP_BATCH может проходить по всей карте от начала до конца. Быстрый путь при пустых корзинах работает еще хуже: он остается внутри одного блока rcu_read_lock() / bpf_disable_instrumentation() для любой последовательности идущих подряд пустых корзин.
Это вызывает проблемы на небольших картах, но становится критичным при масштабировании. На хосте arm64 с 144 ядрами и ядром CONFIG_PREEMPT_NONE периодические вызовы BPF_MAP_LOOKUP_BATCH для LRU-хеша с 16 777 216 корзинами удерживали одно из ядер внутри операции пакета в течение более чем 77 секунд, что приводило к срабатыванию watchdog soft lockup.
Коммит 75134f16e7dd («bpf: Add schedule points in batch ops») исправил эту же проблему для общих операций пакетной обработки (batch ops), но не затронул этот путь htab-native, который используется всеми вариантами хеш-карт на основе htab для своих операций поиска [_and_delete] в пакетах.
Здесь завершается это исправление. Выход из критической секции происходит после 64 идущих подряд пустых корзин; вызывается cond_resched_tasks_rcu_qs(), и выполнение возобновляется с сохраненного курсора корзины. На этот момент никакие блокировки не удерживаются, а возобновление работы от курсора уже является поведением функции для непустых корзин. Тот же самый вызов добавлен в цикл обработки каждой корзины после copy_to_user(), где все блокировки были сняты. cond_resched_rcu() здесь недостаточно: сон при активном bpf_prog_active заставляет трассировочные программы на этом ядре молча пропускать свои вызовы.
Обычный cond_resched() также недостаточен. Он является пустой операцией (no-op) в режимах PREEMPT и PREEMPT_LAZY, которые являются единственными моделями, предоставляемыми arm64 и x86 с момента коммита 7dadeaa6e851 («sched: Further restrict the preemption modes»). Кроме того, он никогда не является состоянием покоя (quiescent state) для Tasks RCU в любой модели: перепланирование считается прерыванием. Задача, выполняющая обход, остается блокирующей и вызывает задержку каждого вызова synchronize_rcu_tasks(), включая очистку ftrace и BPF trampoline, до тех пор, пока системный вызов не вернет управление [1]. cond_resched_tasks_rcu_qs() является стандартным инструментом для решения этой проблемы [2]. Он сообщает о состоянии покоя при каждом yield (предоставлении времени) и все еще выполняет перепланирование так же, как это делает cond_resched(), в ядрах PREEMPT_NONE и PREEMPT_VOLUNTARY.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.