Katalog CVE

CVE-2026-99037

Niskie ryzyko· EPSS 6%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.17%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linux w dm-crypt zaakceptowano nieprawidłową konfigurację łączącą szyfr AEAD z trybem IV lmk (np. "capi:gcm(aes)-lmk"). Tryb lmk ustawia tfms_count na 64, ale crypt_alloc_tfms_aead alokuje tylko jeden transform, co powoduje odczyt poza tablicą tfms_aead i wywołanie crypto_aead_setkey na nieprawidłowych danych, prowadząc do oops przy ładowaniu tabeli.

Ocena ryzyka

Błąd może wywołać awarię jądra (oops) przy ładowaniu specjalnie spreparowanej tabeli dm-crypt. Ponieważ do wywołania wymagane są uprawnienia roota, nie stanowi to wektora eskalacji uprawnień dla zwykłych użytkowników.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę odrzucającą tryb lmk z szyframi AEAD. Unikaj konfiguracji dm-crypt łączących szyfry AEAD z trybem IV lmk.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: dm-crypt: reject the lmk IV mode with AEAD ciphers A "capi:" table line that pairs an AEAD cipher with the lmk IV mode, for example "capi:gcm(aes)-lmk" with the integrity:28:aead option, causes an oops when it is loaded. lmk sets tfms_count to 64, but crypt_alloc_tfms_aead only allocates one transform, so crypt_setkey reads past the end of the tfms_aead array and calls crypto_aead_setkey on the values it finds there. lmk exists for compatibility with Loop-AES, which uses CBC, so refuse it with an AEAD cipher rather than allocate 64 AEAD transforms. The check cannot go in crypt_iv_lmk_ctr with the other lmk checks, because the IV constructor runs after crypt_set_key. Note that this is not a security bug because the memory corruption can only be triggered by root.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS