29 kwietnia 2026 roku publicznie ujawniono CVE-2026-31431, podatność typu local privilege escalation w jądrze Linuksa, nazwaną Copy Fail. Dzień później, 30 kwietnia 2026 roku, CERT-EU opublikował advisory 2026-005, a Canonical opisał wpływ problemu na Ubuntu i udostępnione obejścia. To nie jest zdalne RCE, ale dla administratorów Linuksa sprawa jest poważna: w środowisku, w którym zwykły użytkownik, kontener albo runner CI może wykonywać kod na współdzielonym jądrze, błąd może prowadzić do przejęcia uprawnień roota.
Najważniejszy szczegół techniczny jest prosty: podatność znajduje się w module algif_aead, czyli części interfejsu AF_ALG, który wystawia kernelowe funkcje kryptograficzne do przestrzeni użytkownika. Według CERT-EU podatność ma wynik CVSS 3.1 równy 7.8 i wynika z optymalizacji wprowadzonej w 2017 roku w kodzie algif_aead. Poprawka w mainline, commit a664bf3d603d, została zatwierdzona 1 kwietnia 2026 roku i odwraca problematyczny mechanizm pracy in-place.
Co dokładnie się wydarzyło
Copy Fail wykorzystuje połączenie operacji na gnieździe AF_ALG z mechanizmem splice(). W uproszczeniu: nieuprzywilejowany proces może doprowadzić do kontrolowanego, 4-bajtowego zapisu w stronie pamięci należącej do page cache. To istotne, ponieważ page cache przechowuje w RAM kopie danych odczytywanych z plików. Jeżeli atakujący potrafi zmienić bajty w pamięciowej kopii programu z bitem setuid, takiego jak /usr/bin/su, może uzyskać wykonanie kodu z uprawnieniami roota.
To odróżnia Copy Fail od wielu podatności kernelowych, które wymagają trafienia w trudne okno czasowe, dopasowania offsetów do konkretnej kompilacji kernela albo niestabilnego łańcucha eksploatacji. Strona badaczy opisuje problem jako logiczny błąd w ścieżce authencesn, połączony z AF_ALG i splice(). Publicznie dostępny proof of concept oznacza, że organizacje nie powinny traktować podatności jako teoretycznej.
Dlaczego to jest ważne dla admina, DevOpsa i power usera
Podatność jest lokalna, więc sama w sobie nie daje wejścia z internetu. Ryzyko pojawia się tam, gdzie lokalne wykonanie kodu jest normalną częścią platformy. W praktyce dotyczy to serwerów developerskich, bastionów, hostów z wieloma kontami, systemów uruchamiających zadania CI/CD, środowisk kontenerowych oraz usług, które wykonują kod użytkowników. W takich miejscach granica między „zwykłym userem” a „rootem na hoście” jest krytyczną linią obrony.
Najbardziej nerwowa kategoria to kontenery. Kontener nie jest maszyną wirtualną; dzieli kernel z hostem. Jeżeli workload w kontenerze może otworzyć AF_ALG i wykorzystać błąd w jądrze, to problem przestaje być wyłącznie lokalnym LPE w ramach jednego konta. Staje się ścieżką do eskalacji na węźle, a dalej potencjalnie do ruchu bocznego w klastrze. CERT-EU wprost wskazał priorytet dla Kubernetes nodes i runnerów CI/CD wykonujących niezaufane workloady.
W przypadku klasycznego serwera produkcyjnego, na którym konta mają tylko zaufani administratorzy, ryzyko jest niższe, ale nadal realne. Każdy błąd aplikacyjny dający wykonanie kodu jako użytkownik serwisowy, przejęty klucz SSH albo podatny plugin webowy może zostać połączony z Copy Fail jako etap podniesienia uprawnień. Dlatego podatność należy traktować jako element łańcucha ataku, a nie wyłącznie jako problem hostingu współdzielonego.
Które systemy są narażone
Według CERT-EU problem dotyczy mainstreamowych dystrybucji Linuksa z kernelami zbudowanymi od 2017 roku do momentu wdrożenia poprawki. Badacze bezpośrednio zweryfikowali podatność między innymi na Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 oraz SUSE 16. Ubuntu w swoim opisie CVE wskazało wysoki priorytet i określiło problem jako trywialną lokalną eskalację uprawnień.
Canonical podał 30 kwietnia 2026 roku, że podatność dotyczy wydań Ubuntu przed Resolute 26.04. Ubuntu 26.04 LTS Resolute nie jest wskazane jako podatne w tym komunikacie. Dla starszych wspieranych wydań Canonical udostępnił mitigację przez pakiet kmod, która wyłącza podatny moduł. Docelowa poprawka ma trafić przez pakiety obrazu kernela.
W praktyce administrator powinien sprawdzić stan u konkretnego dostawcy dystrybucji, a nie zakładać, że numer kernela sam wystarczy. W środowiskach enterprise dochodzą warianty kernelowe dla chmur, HWE, livepatchingu, appliance’ów i systemów embedded. Ta sama nazwa dystrybucji może oznaczać różne pakiety kernela na bare metalu, w chmurze i na hostach kontenerowych.
Co sprawdzić na własnych hostach
Pierwszy krok to inwentaryzacja: wersja działającego kernela, pakiety kernelowe, obecność modułu algif_aead oraz workloady, które mogą używać AF_ALG. Na Ubuntu przydatne są polecenia wskazane przez Canonical. W innych dystrybucjach odpowiednikiem będzie lokalny menedżer pakietów i tracker bezpieczeństwa dostawcy.
uname -r
lsmod | grep '^algif_aead' || true
grep -qE '^algif_aead ' /proc/modules && echo 'algif_aead loaded' || echo 'algif_aead not loaded'
# Ubuntu/Debian: pakiety kernela i kmod
dpkg -l 'linux-image*' | grep '^ii'
dpkg -l kmod
# Procesy używające AF_ALG, jeżeli lsof jest dostępny
sudo lsof 2>/dev/null | grep AF_ALG || trueWarto rozdzielić hosty na grupy ryzyka. Pierwsza grupa to węzły Kubernetes, hosty Docker/Podman i self-hosted runners. Druga to maszyny z wieloma kontami użytkowników: serwery developerskie, jump hosty, systemy edukacyjne, build farmy. Trzecia to single-tenant produkcja bez kont użytkowników poza administracją. Wszystkie wymagają poprawki, ale kolejność wdrożenia nie powinna być przypadkowa.
Mitigacja przed pełnym patchem
Najlepszym rozwiązaniem jest aktualizacja kernela do wersji zawierającej właściwą poprawkę. Jeżeli poprawiony kernel nie jest jeszcze dostępny albo okno restartowe jest odległe, zalecanym obejściem jest wyłączenie modułu algif_aead. Canonical dostarczył takie obejście w pakiecie kmod, a CERT-EU zaleca trwałe zablokowanie modułu do czasu instalacji poprawionego kernela.
# Ubuntu: aktualizacja pakietów bezpieczeństwa
sudo apt update
sudo apt upgrade
# Jeżeli trzeba celować tylko w mitigację kmod
sudo apt update
sudo apt install --only-upgrade kmod
# Ręczne zablokowanie modułu przed pełnym patchem
printf 'install algif_aead /bin/false\n' | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true
grep -qE '^algif_aead ' /proc/modules && echo 'module still loaded' || echo 'module blocked or not loaded'Takie obejście może mieć skutki uboczne dla aplikacji, które świadomie korzystają z AF_ALG, na przykład przez specjalną konfigurację silnika kryptograficznego. Według informacji badaczy nie powinno to wpływać na typowe użycie LUKS/dm-crypt, SSH, OpenSSL, GnuTLS, NSS czy IPsec/XFRM, jeżeli aplikacje nie przechodzą przez użytkowy front door AF_ALG. Mimo to w środowiskach o niestandardowej akceleracji kryptografii trzeba wykonać testy regresji.
Kontenery i CI/CD: nie wystarczy patrzeć na pakiety
Dla platform kontenerowych praktyczną warstwą obrony jest seccomp. CERT-EU rekomenduje blokowanie tworzenia gniazd AF_ALG w kontenerach i pipeline’ach niezależnie od statusu patcha. Ma to sens operacyjny: exploit musi rozpocząć się od otwarcia takiego gniazda, więc odcięcie tej ścieżki zmniejsza ekspozycję nawet przed restartem hosta z poprawionym kernelem.
Administrator klastra powinien sprawdzić profile seccomp używane przez runtime, polityki podów oraz wyjątki dla workloadów uprzywilejowanych. Szczególnej uwagi wymagają runnerzy CI, bo często wykonują kod z pull requestów, instalują zależności z internetu i mają dostęp do sekretów buildowych. W takim modelu lokalna eskalacja uprawnień na runnerze może prowadzić do kradzieży tokenów, modyfikacji artefaktów albo dalszego ataku na sieć wewnętrzną.
- Najpierw patchuj węzły kontenerowe, self-hosted runners, build farmy i hosty z wieloma użytkownikami.
- Zablokuj
algif_aead, jeżeli poprawiony kernel nie jest jeszcze wdrożony albo restart musi poczekać. - Ogranicz
AF_ALGw kontenerach przez seccomp, zwłaszcza dla niezaufanych workloadów. - Sprawdź zależności, jeżeli masz aplikacje jawnie używające kernelowego interfejsu kryptograficznego z userspace.
- Nie uruchamiaj publicznego PoC na produkcji; do walidacji używaj środowiska testowego albo informacji z pakietów dostawcy.
Praktyczne podsumowanie
Copy Fail to świeży przykład podatności, która nie musi być zdalna, aby była pilna. Ujawnienie z 29 kwietnia 2026 roku dotyka granicy bezpieczeństwa między użytkownikiem, kontenerem i hostem. Dla administratora najrozsądniejsza kolejność działań to: zinwentaryzować hosty, zaktualizować pakiety bezpieczeństwa, zablokować algif_aead tam, gdzie kernel nie jest jeszcze poprawiony, oraz wymusić profile seccomp blokujące AF_ALG w kontenerach i CI/CD. Dopiero po wdrożeniu poprawionego kernela i restarcie można traktować obejścia jako tymczasowe i zaplanować ich wycofanie po testach.
