Jądro Linuksa: naprawiono wyścig o IV w algif_skcipher (CVE-2026-74578)

W jądrze Linuksa załatano podatność typu race condition w module algif_skcipher, czyli interfejsie udostępniającym userspace’owi symetryczne algorytmy szyfrowania przez gniazda AF_ALG. Skutkiem mogło być odzyskanie tekstu jawnego przez nieuprzywilejowanego użytkownika.

Na czym polegał problem

Najpierw jedno wyjaśnienie, bo w opisach tej luki często pojawia się skrót myślowy. Wektor inicjujący (IV) nie jest kluczem — to osobna, jawna wartość, która sprawia, że ten sam tekst zaszyfrowany tym samym kluczem daje za każdym razem inny wynik. Jej tajność nie jest wymagana; wymagana jest unikalność. I właśnie o złamanie tej unikalności tu chodzi.

Mechanizm wyglądał tak:

1. ścieżka asynchroniczna (AIO) w funkcji skcipher_recvmsg() przekazywała wspólny dla gniazda ctx->iv bezpośrednio do żądania,
2. po wywołaniu io_submit() blokada gniazda była zwalniana, a żądanie przetwarzane w tle,
3. w tym oknie równoległe wywołanie sendmsg(ALG_SET_IV) mogło nadpisać ctx->iv,
4. trwające żądanie kończyło się z wektorem kontrolowanym przez atakującego.

W trybach licznikowych (CTR) i strumieniowych powtórzenie IV przy tym samym kluczu oznacza powtórzenie strumienia klucza — a to pozwala nieuprzywilejowanemu użytkownikowi odtworzyć tekst jawny operacji wykonywanej równolegle przez kogoś innego.

Dlaczego naprawiono to akurat tak

Ciekawy jest tu opis odrzuconych rozwiązań. Zwykłe skopiowanie IV do pamięci per-żądanie nie wystarczało: dla szyfrów o statesize == 0 (czyli m.in. CBC i CTR) łańcuchowanie IV między porcjami przy MSG_MORE opiera się wyłącznie na zapisie zwrotnym w miejscu, więc kopia przekierowałaby zapis do pamięci zwalnianej po zakończeniu operacji — dając po cichu błędne wyniki. Zapis IV z callbacku zakończenia też odpada, bo wymagałby lock_sock(), a callback może działać w kontekście softirq, gdzie nie wolno zasypiać.

Pozostało wymuszenie przetwarzania synchronicznego, co usuwa naraz wyścig o IV i wyścig zapisu zwrotnego. W mainlinie ten sam efekt osiągnięto szerzej — commitem usuwającym obsługę AIO dla gniazd w całym net/. Łatka dla gałęzi stabilnych celowo od tego odbiega i wycina jedynie gałąź AIO w crypto/algif_skcipher.c, bo zmiana ogólnosystemowa byłaby dla stabilnych zbyt inwazyjna.

Uwaga: poprawka ma koszt

To warto powiedzieć wprost. io_submit() kończy się teraz synchronicznie, czyli asynchroniczne operacje AF_ALG przestają być asynchroniczne. Jeśli jakaś aplikacja opierała na tym wydajność, po aktualizacji zachowa się inaczej. Dla zdecydowanej większości systemów nie ma to znaczenia, ale dla wąskiej grupy zastosowań to realna zmiana.

Czy to Cię dotyczy?

Prawdopodobnie nie — i wbrew nagłówkom nie jest to podatność dotykająca każdego użytkownika Linuksa. AF_ALG to niszowy interfejs, z którego typowe oprogramowanie nie korzysta: dm-crypt/LUKS, kTLS, IPsec, OpenSSL, GnuTLS czy SSH działają poza nim. Realnie narażone są aplikacje jawnie skonfigurowane do używania silnika afalg albo bezpośrednio otwierające gniazda AF_ALG.

Ekspozycję sprawdzisz poleceniem:

lsof | grep AF_ALG

Konkretne wersje jądra objęte podatnością i zawierające poprawkę najlepiej sprawdzić w trackerze bezpieczeństwa swojej dystrybucji, bo backporty do gałęzi stabilnych trafiają w różnym tempie.

Szerszy kontekst: AF_ALG wraca jak bumerang

To nie jest odosobniony przypadek. W kwietniu 2026 ujawniono CVE-2026-31431, nazwane „Copy Fail” — podatność w siostrzanym module algif_aead o ocenie CVSS 7,8, pozwalającą lokalnemu użytkownikowi uzyskać uprawnienia roota w kilka sekund, z publicznie dostępnymi exploitami dla kilku dystrybucji. Regresja pochodziła z optymalizacji wprowadzonej w 2017 roku.

Jeśli Twoje systemy nie korzystają z AF_ALG, rozsądnym zabezpieczeniem na przyszłość jest po prostu zablokowanie ładowania tych modułów — to standardowe zalecenie wydawane przy okazji poprzedniej podatności.

Źródła: NVD, kernel.org (linux-cve-announce), Red Hat Customer Portal, CERT-EU