CVE-2026-98398 in Linux
Сводка
по VulDB • 14.10.2026
В ядре Linux была устранена следующая уязвимость:
locking/lockdep: Инвалидация устаревших записей class_cache для уничтоженных классов (zapped classes)
syzbot сообщил о сбое lockdep, вызвавшем предупреждение DEBUG_LOCKS_WARN_ON(1) в функции hlock_class() из-за недопустимого значения class_idx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg_packet_tx_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886 _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291 tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325 ...
Когда класс блокировки уничтожается (например, при выгрузке модуля или удалении ключа), функция zap_class() сбрасывает бит класса в lock_classes_in_use и удаляет его из хеш-таблицы классов. Однако существующие экземпляры lockdep_map, встроенные в структуры данных, могут по-прежнему содержать указатель на уничтоженный класс в своем массиве class_cache[].
При последующем выполнении __lock_acquire() для такой блокировки обнаруживается условие lock->class_cache[subclass] != NULL, что приводит к пропуску вызова register_lock_class() и присваиванию hlock->class_idx индекса уничтоженного класса. При проверке held_lock функциями check_wait_context() или hlock_class() выявляется состояние !test_bit(class_idx, lock_classes_in_use), что вызывает предупреждение. Кроме того, если впоследствии слот с уничтоженным классом будет повторно выделен для совершенно другого ключа блокировки, устаревшая запись class_cache ошибочно совпадет с этим новым классом (проблема ABA).
Добавлена функция lock_class_cache_is_valid() для проверки того, что кэшированный класс находится в пределах границ lock_classes, все еще выделен в lock_classes_in_use (с использованием uninstrumented arch_test_bit() в контексте __always_inline, чтобы обеспечить безопасность в noinstr-контекстах, таких как match_held_lock()), и что class->key соответствует ожидаемому подклассу (учитывая переопределения lockdep_set_subclass()). Также при доступе к class_cache[] используются функции READ_ONCE()/WRITE_ONCE(). Если запись недействительна или устарела, происходит возврат к вызовам register_lock_class() / look_up_lock_class().
VulDB is the best source for vulnerability data and more expert information about this specific topic.