Odebrany

CVE-2026-98398

opublikowano: 14.10.2026, 16:17

modyfikacja: 14.10.2026, 16:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

blokowanie/lockdep: Unieważnia nieaktualne wpisy class_cache dla przeniesionych klas

syzbot zgłosił, że uderzenie blokady w DEBUG_LOCKS_WARN_ON(1) w
hlock_class() z powodu nieprawidłowego identyfikatora klasy:

OSTRZEŻENIE: kernel/locking/lockdep.c:238 w __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Kolejka robocza: 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 jądro/locking/lockdep.c:5203
Zadzwoń do śledzenia:
<przerwanie>
lock_acquire+0x106/0x350 jądro/locking/lockdep.c:5886
_raw_spin_lock+0x2e/0x40 jądro/blokowanie/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
...

Kiedy klasa blokady jest zapakowana (np. podczas rozładowywania modułu lub wykonywania polecenia key
wyrejestrowanie), zap_class() czyści bit klasy
lock_classes_in_use i usuwa go z tablicy mieszającej klasy.
Jednakże istniejące instancje lockdep_map osadzone w strukturach danych
mogą nadal zachować wskaźnik do zapakowanej klasy w swoim class_cache[]
tablica.

Kiedy __lock_acquire() następnie uruchamia taką blokadę, znajduje
lock->class_cache[podklasa] != NULL, pomijanie Register_lock_class()
i przypisanie hlock->class_idx do indeksu zapakowanej klasy. Kiedy
check_wait_context() lub hlock_class() sprawdza hold_lock i znajduje
!test_bit(class_idx, lock_classes_in_use) i ostrzega. Ponadto, jeśli
zajęte miejsce jest następnie ponownie przydzielane niepowiązanemu kluczowi zamka,
nieaktualny wpis class_cache błędnie pasowałby do niepowiązanego wpisu
klasa (problem ABA).

Dodaj funkcję lock_class_cache_is_valid(), aby sprawdzić, czy klasa w pamięci podręcznej jest
w granicach lock_classes, nadal przydzielane w lock_classes_in_use
(używając nieinstrumentowanej funkcji arch_test_bit() w kontekście __always_inline, więc tak
jest bezpieczny w kontekstach noinstr, takich jak match_held_lock()) i to
class->key pasuje do oczekiwanego podklucza (biorąc pod uwagę lockdep_set_subclass()
nadpisania pod uwagę). Użyj także READ_ONCE()/WRITE_ONCE() kiedy
uzyskiwanie dostępu do pamięci podręcznej klasy []. Jeśli wpis jest nieprawidłowy lub nieaktualny, cofnij się
do Register_lock_class() / look_up_lock_class().

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:
<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
...

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().

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve