CVE-2026-98398 in Linux
Resumen
por VulDB • 2026-10-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
locking/lockdep: Invalidar las entradas obsoletas del class_cache para clases zapped (eliminadas)
syzbot reportó un fallo en lockdep que activaba DEBUG_LOCKS_WARN_ON(1) en hlock_class() debido a un class_idx no válido:
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: <IRQ> 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 ...
Cuando una clase de bloqueo se zappa (por ejemplo, durante la descarga del módulo o el desregistro de claves), zap_class() borra el bit correspondiente a dicha clase en lock_classes_in_use y la elimina de la tabla hash de clases. Sin embargo, las instancias existentes de lockdep_map incrustadas en estructuras de datos pueden seguir conservando un puntero a la clase zapped en su array class_cache[].
Cuando __lock_acquire() se ejecuta posteriormente sobre dicho bloqueo, detecta que lock->class_cache[subclass] != NULL, omite register_lock_class() y asigna hlock->class_idx al índice de la clase zapped. Cuando check_wait_context() o hlock_class() inspeccionan el held_lock (bloqueo retenido), encuentran !test_bit(class_idx, lock_classes_in_use) y generan una advertencia. Además, si la ranura zapped se vuelve a asignar posteriormente a una clave de bloqueo no relacionada, la entrada obsoleta del class_cache coincidiría erróneamente con la clase no relacionada (problema ABA).
Se añade lock_class_cache_is_valid() para validar que la clase en caché está dentro de los límites de lock_classes, sigue asignada en lock_classes_in_use (utilizando arch_test_bit() sin instrumentar en un contexto __always_inline para que sea seguro en contextos noinstr como match_held_lock()), y que class->key coincide con el subclave esperado (teniendo en cuenta las anulaciones de lockdep_set_subclass()). También se utiliza READ_ONCE()/WRITE_ONCE() al acceder a class_cache[]. Si la entrada es inválida u obsoleta, se vuelve a register_lock_class() / look_up_lock_class().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.