Dwie krytyczne luki w kernelu Linux — eskalacja do roota

Na czym polega problem

Luka tkwi w module algif_aead — składniku kernela obsługującym operacje kryptograficzne AEAD przez interfejs gniazd AF_ALG. W 2017 roku wprowadzono optymalizację polegającą na wykonywaniu szyfrowania w miejscu (in-place): kernel ponownie używał bufora źródłowego jako docelowego. Ta pozornie niegroźna zmiana stworzyła nieoczekiwaną ścieżkę: przez połączenie wywołań systemowych socket(AF_ALG) i splice() nieuprawniony użytkownik może wykonać precyzyjny zapis 4-bajtowy bezpośrednio do page cache — mechanizmu przechowującego w pamięci aktywne kopie plików z dysku.

Atakujący modyfikuje w pamięci kod pliku wykonywalnego z bitem setuid (np. /usr/bin/su) — bez dotykania pliku na dysku. Gdy dowolny uprzywilejowany proces uruchomi tę skażoną kopię, atakujący otrzymuje powłokę roota. Cały exploit to 732-bajtowy skrypt Pythona korzystający wyłącznie z biblioteki standardowej. Nie wymaga warunków wyścigowych, nie zawiesza systemu i działa na wszystkich testowanych dystrybucjach bez modyfikacji. Plik na dysku pozostaje niezmieniony — systemy detekcji oparte na sumach kontrolnych nie zauważą włamania.

Dotyczy systemów

Wszystkie dystrybucje zbudowane na kernelu wydanym od 2017 roku (od ok. wersji 4.14) do wersji poprawionych. Potwierdzone: Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16, Debian, Fedora, Arch Linux.

Jak sprawdzić podatność

Sprawdź wersję działającego kernela i oceń, czy moduł algif_aead jest załadowany:

# Sprawdź wersję kernela
uname -r

# Sprawdź czy moduł jest załadowany
lsmod | grep algif_aead

# Sprawdź czy moduł jest dostępny w systemie
find /lib/modules/$(uname -r) -name 'algif_aead*'

# Sprawdź czy coś aktualnie korzysta z AF_ALG
lsof | grep AF_ALG

Jeśli lsmod zwraca wynik lub find odnajduje plik modułu, system jest podatny (o ile nie ma jeszcze zaktualizowanego kernela). Wersje podatne to kernel 4.14 – 6.18.21 oraz 6.19.x przed 6.19.12.

Na czym polega problem

Zaledwie tydzień po Copy Fail, badacz Hyunwoo Kim ujawnił kolejną rodzinę luk opartą na tym samym mechanizmie zapisu do page cache, ale działającą przez zupełnie inne podsystemy kernela. Dirty Frag łączy dwa niezależne błędy w jedną niezawodną ścieżkę eskalacji uprawnień.

CVE-2026-43284 dotyczy modułów esp4 i esp6 — implementacji protokołu ESP (Encapsulating Security Payload) dla IPv4 i IPv6, stanowiącego serce VPN opartych na IPsec. Optymalizacja ścieżki szybkiego odbioru z 2017 roku sprawiła, że deszyfrowanie może odbywać się na buforach stronnicowanych (paged buffers), które nie należą wyłącznie do kernela. Przez splice() lub vmsplice() nieuprawniony proces może zachować referencję do odszyfrowanego tekstu jawnego, uzyskując tym samym prymityw zapisu do page cache.

CVE-2026-43500 dotyczy modułu rxrpc implementującego protokół RxRPC, na którym opiera się rozproszony system plików AFS. Ten sam błąd in-place decryption — wprowadzony w czerwcu 2023 — tworzy identyczną ścieżkę zapisu.

Łącząc oba błędy, atakujący uzyskuje nie tylko zapis 4-bajtowy (jak w Copy Fail), lecz zapis pełnego, atakującym kontrolowanego tekstu jawnego w dowolne miejsce page cache — w jednym poleceniu. Co istotne: systemy zabezpieczone przez wyłączenie algif_aead (jako mitygacja Copy Fail) nadal są podatne na Dirty Frag.

Dotyczy systemów

Wszystkie główne dystrybucje. CVE-2026-43284 (ESP) — kernele od 2017 roku. CVE-2026-43500 (RxRPC) — kernele od połowy 2023 roku. AlmaLinux 8 jest podatny tylko na CVE-2026-43284 (brak modułu rxrpc). AlmaLinux 9 i 10 podatne na obie luki. Wyjątek: CloudLinux 7 nie jest podatny.

Jak sprawdzić podatność

# Sprawdź wersję kernela
uname -r

# Sprawdź załadowanie modułów ESP (CVE-2026-43284)
lsmod | grep -E 'esp4|esp6'

# Sprawdź moduł rxrpc (CVE-2026-43500)
lsmod | grep rxrpc

# Sprawdź dostępność modułów w systemie
find /lib/modules/$(uname -r) -name 'esp4*' -o -name 'esp6*' -o -name 'rxrpc*'

# Jeśli używasz KernelCare – sprawdź stan łatki
kcarectl --patch-info | grep -i 'CVE-2026-43284\|CVE-2026-43500'

Jeżeli moduły esp4, esp6 lub rxrpc są załadowane lub dostępne w katalogu modułów, a kernel nie pochodzi z zaufanego pakietu z poprawką, system jest podatny.