PT-2026-114377 · Linux · Linux
CVE-2026-98398
·
Publicado
2026-10-14
·
Atualizado
2026-10-14
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Invalidate stale class cache entries for zapped classes
syzbot reported a lockdep splat hitting DEBUG LOCKS WARN ON(1) in
hlock class() due to an invalid 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
...
When a lock class is zapped (e.g. during module unload or key
unregistration), zap class() clears the class's bit in
lock classes in use and removes it from the class hash table.
However, existing lockdep map instances embedded in data structures
may still retain a pointer to the zapped class in their class cache[]
array.
When lock acquire() subsequently runs on such a lock, it finds
lock->class cache[subclass] != NULL, skipping register lock class()
and assigning hlock->class idx to the index of the zapped class. When
check wait context() or hlock class() inspects the held lock, it finds
!test bit(class idx, lock classes in use) and warns. Furthermore, if
the zapped slot is subsequently re-allocated to an unrelated lock key,
the stale class cache entry would erroneously match the unrelated
class (ABA issue).
Add lock class cache is valid() to validate that the cached class is
within lock classes bounds, still allocated in lock classes in use
(using uninstrumented arch test bit() in always inline context so it
is safe in noinstr contexts like match held lock()), and that
class->key matches the expected subkey (taking lockdep set subclass()
overrides into account). Also use READ ONCE()/WRITE ONCE() when
accessing class cache[]. If the entry is invalid or stale, fall back
to register lock class() / look up lock class().
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux