Copy Fail: nowa luka w jądrze Linuksa, która zmienia lokalnego użytkownika w roota

29 kwietnia 2026 r. zespół Theori/Xint opublikował szczegóły podatności CVE-2026-31431, nazwanej Copy Fail. To nie jest zdalne RCE ani błąd w popularnej bibliotece użytkowej, lecz lokalna eskalacja uprawnień w jądrze Linuksa. W praktyce oznacza to, że użytkownik lub proces, który już wykonuje kod na podatnej maszynie, może podnieść uprawnienia do roota. Dla pojedynczej stacji roboczej brzmi to jak etap po kompromitacji. Dla hostów wieloużytkownikowych, runnerów CI/CD, systemów uruchamiających cudzy kod oraz węzłów Kubernetes jest to dużo poważniejszy problem operacyjny.

Najważniejsze fakty są konkretne: publiczne ujawnienie nastąpiło 29 kwietnia 2026 r., CVE zostało przypisane 22 kwietnia 2026 r., a poprawka w głównej gałęzi jądra została zatwierdzona 1 kwietnia 2026 r. Według opisu badaczy błąd dotyczy ścieżki algif_aead, czyli interfejsu AEAD w kernelowym API kryptograficznym dostępnym z przestrzeni użytkownika przez gniazda AF_ALG. Problem polega na tym, że połączenie AF_ALG, splice() oraz konkretnego szablonu kryptograficznego authencesn pozwala wykonać kontrolowany zapis 4 bajtów do page cache pliku, który użytkownik może odczytać.

Co dokładnie się wydarzyło

Copy Fail został opisany jako błąd logiczny, a nie klasyczny wyścig czasowy. To istotne, bo wiele wcześniejszych podatności LPE w Linuksie wymagało precyzyjnego trafienia w okno czasowe albo dopasowania exploita do konkretnej wersji jądra. W tym przypadku badacze pokazali ścieżkę, w której użytkownik bez uprawnień może wykorzystać standardowe wywołania systemowe oraz domyślnie dostępny interfejs kryptograficzny jądra.

W uproszczeniu podatność dotyka sytuacji, w której dane pliku trafiają przez splice() do operacji kryptograficznej obsługiwanej przez kernel. Optymalizacja wprowadzona w 2017 r. spowodowała, że w określonej ścieżce przetwarzania AEAD page cache mógł znaleźć się w strukturze traktowanej jak bufor zapisu. Szablon authencesn używał natomiast fragmentu bufora jako przestrzeni roboczej i wykonywał zapis poza oczekiwanym obszarem wyjściowym. Efektem jest możliwość zmiany kilku bajtów w pamięci podręcznej pliku, bez modyfikacji pliku na dysku.

Ten szczegół jest bardzo ważny dla administratorów. Jeżeli zmiana zachodzi w page cache, klasyczne porównanie sum kontrolnych pliku na dysku może niczego nie wykazać. Plik w systemie plików pozostaje nietknięty, ale proces uruchamiający binarkę może dostać jej zmodyfikowaną wersję z pamięci. W demonstracji badacze użyli tego do modyfikacji setuidowego programu takiego jak /usr/bin/su, co pozwala uzyskać powłokę z UID 0.

Kogo to realnie dotyczy

Największe ryzyko nie dotyczy laptopa jednego administratora, lecz systemów, na których wiele podmiotów współdzieli ten sam kernel. Copy Fail jest lokalną eskalacją uprawnień, więc atakujący musi najpierw uruchomić kod na maszynie. W erze kontenerów i automatyzacji to założenie nie jest jednak egzotyczne. Wiele środowisk z definicji wykonuje kod dostarczany przez użytkowników, developerów, klientów, studentów albo pipeline’y.

• Węzły Kubernetes — szczególnie klastry uruchamiające workloady wielu zespołów lub tenantów. Kontenery współdzielą kernel hosta, więc lokalny błąd jądra zmienia model ryzyka.
• Self-hosted runners CI/CD — GitLab Runner, Jenkins agent, Buildkite, Drone, GitHub Actions self-hosted runner i podobne systemy wykonują kod z repozytoriów oraz pull requestów.
• Serwery shellowe, bastiony i jump hosty — każdy lokalny użytkownik staje się potencjalnym punktem eskalacji.
• Platformy edukacyjne, CTF, notebooki i sandboxy — systemy projektowane do uruchamiania nie w pełni zaufanego kodu powinny traktować tę klasę błędu priorytetowo.
• Serwery po podatności webowej — nawet jeżeli aplikacja daje atakującemu tylko niski poziom dostępu, Copy Fail może być kolejnym etapem łańcucha.

Canonical w komunikacie z 30 kwietnia 2026 r. wskazał, że podatność dotyczy wydań Ubuntu sprzed Ubuntu 26.04 LTS Resolute Raccoon, a Ubuntu 26.04 nie wymaga aktualizacji w tym zakresie. Jednocześnie dla wcześniejszych wydań Ubuntu opublikowano mitigację w pakiecie kmod, która wyłącza podatny moduł. CERT-EU w doradztwie z 30 kwietnia 2026 r. rekomendował natychmiastowe zastosowanie obejścia oraz priorytetowe potraktowanie węzłów Kubernetes i runnerów CI/CD.

Jak sprawdzić systemy Linux

Pierwszy krok to inwentaryzacja kerneli i dystrybucji. Nie wystarczy sprawdzić wersji pakietu zainstalowanego na dysku — liczy się kernel aktualnie uruchomiony. Po aktualizacji pakietu jądra host często nadal działa na starej wersji do momentu restartu. W środowiskach produkcyjnych warto zestawić dane z CMDB, Ansible inventory, systemu EDR oraz orkiestratora kontenerów.

uname -r
cat /etc/os-release

# Debian/Ubuntu: zainstalowane obrazy jądra
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

# RHEL/Rocky/Alma/Fedora/Amazon Linux: pakiety kernel
rpm -qa 'kernel*' | sort

# Czy moduł jest załadowany
lsmod | grep '^algif_aead' || true

# Sygnały użycia AF_ALG przez procesy
ss -xa | grep -i alg || true
lsof 2>/dev/null | grep AF_ALG || true

W przypadku Ubuntu należy dodatkowo sprawdzić pakiet kmod, ponieważ to właśnie on może zawierać tymczasową blokadę modułu. Dla hostów opartych o inne dystrybucje najbezpieczniejszą ścieżką jest śledzenie oficjalnych advisory vendorów, a nie poleganie wyłącznie na numerze wersji upstream. Dystrybucje enterprise często backportują poprawki bez zmiany widocznej wersji jądra na taką, jaka występuje w głównej linii rozwoju.

Mitigacja przed pełną aktualizacją jądra

Docelowym rozwiązaniem jest aktualizacja kernela do wersji zawierającej poprawkę albo do backportu przygotowanego przez dostawcę dystrybucji. Tam, gdzie nie da się tego zrobić natychmiast, praktycznym obejściem jest zablokowanie modułu algif_aead. Trzeba jednak pamiętać o regresjach: jeżeli jakaś aplikacja faktycznie używa AF_ALG do operacji AEAD, może wymagać przełączenia na kryptografię w przestrzeni użytkownika lub restartu procesu.

# Tymczasowa i trwała blokada ładowania algif_aead
sudo install -m 0644 /dev/null /etc/modprobe.d/disable-algif-aead.conf
printf 'install algif_aead /bin/false\nblacklist algif_aead\n' | sudo tee /etc/modprobe.d/disable-algif-aead.conf

# Próba usunięcia modułu z działającego kernela
sudo modprobe -r algif_aead 2>/dev/null || true
sudo rmmod algif_aead 2>/dev/null || true

# Weryfikacja
lsmod | grep '^algif_aead' || echo 'algif_aead nie jest załadowany'

W systemach z Secure Boot, własnymi obrazami initramfs lub mocno zautomatyzowanym bootstrappingiem trzeba sprawdzić, czy konfiguracja z /etc/modprobe.d/ jest rzeczywiście uwzględniana po restarcie. Jeżeli moduł jest wkompilowany na stałe, a nie ładowany jako moduł, prosta blokada przez modprobe może nie wystarczyć. Wtedy większe znaczenie mają seccomp, aktualizacja kernela albo przebudowa konfiguracji jądra bez podatnej ścieżki.

Kontenery: dlaczego seccomp ma tu znaczenie

Copy Fail przypomina, że kontener nie jest maszyną wirtualną. Proces w kontenerze nadal wykonuje wywołania systemowe wobec kernela hosta. Jeżeli host ma podatny kernel i profil seccomp pozwala na utworzenie gniazda AF_ALG, podatna ścieżka może być osiągalna z workloadu. Dlatego środowiska Docker, Podman i Kubernetes powinny ograniczać możliwość tworzenia niepotrzebnych rodzin gniazd, zwłaszcza dla workloadów nieuprzywilejowanych.

W Kubernetes warto sprawdzić trzy obszary. Po pierwsze: czy klastry używają profili seccomp innych niż Unconfined. Po drugie: czy build runnery i joby CI nie działają jako kontenery uprzywilejowane. Po trzecie: czy workloady mają ograniczone capabilities, w szczególności nie powinny rutynowo dostawać CAP_SYS_ADMIN, CAP_SYS_MODULE ani dostępu do hostPath tam, gdzie nie jest to absolutnie konieczne.

Detekcja i monitoring

Detekcja Copy Fail powinna skupiać się na nietypowym użyciu AF_ALG, a nie na próbie znajdowania zmodyfikowanych plików na dysku. Jeżeli sedno ataku dotyczy page cache, kontrola integralności samego pliku może dawać fałszywe poczucie bezpieczeństwa. Sysdig opisał regułę dla Falco wykrywającą tworzenie gniazd AF_ALG typu SOCK_SEQPACKET przez procesy spoza znanych narzędzi kryptograficznych. Taki sygnał może wymagać strojenia, ale w środowiskach serwerowych zwykle nie powinien pojawiać się masowo.

W praktyce warto dodać alerty na:

• tworzenie gniazd AF_ALG przez procesy aplikacyjne, skrypty, interpretery i kontenery buildowe,
• uruchamianie setuidowych binarek przez nietypowe procesy potomne,
• nagłe przejścia UID z konta technicznego lub użytkownika aplikacyjnego do UID 0,
• workloady CI wykonujące niskopoziomowe wywołania socket, splice, sendmsg i recvmsg w nietypowej kombinacji,
• kontenery uruchamiane jako privileged albo z profilem seccomp ustawionym na Unconfined.

Plan działania dla administratora

Najlepsza reakcja to nie panika, tylko szybka klasyfikacja ryzyka. Hosty bez lokalnych użytkowników i bez wykonywania niezaufanego kodu są mniej pilne niż klastry, bastiony i runnery. Nie oznacza to, że można je ignorować: lokalna eskalacja świetnie łączy się z podatnością aplikacji webowej, wyciekiem klucza SSH albo błędną konfiguracją kontenera.

1. Zidentyfikuj hosty wysokiego ryzyka: Kubernetes, CI/CD, bastiony, serwery wielu użytkowników, sandboxy, platformy z kodem użytkowników.
2. Sprawdź aktywny kernel, a nie tylko dostępność aktualizacji.
3. Wdróż poprawkę dostawcy, gdy jest dostępna, i zaplanuj restart tam, gdzie wymaga tego kernel.
4. Zastosuj blokadę algif_aead jako obejście, jeżeli pełna aktualizacja nie może wejść natychmiast.
5. Ogranicz AF_ALG w kontenerach przez seccomp, szczególnie dla nieufanych workloadów.
6. Dodaj reguły detekcji dla nietypowego użycia AF_ALG i eskalacji do UID 0.

Podsumowanie praktyczne

Copy Fail to podatność, którą administratorzy Linuksa powinni potraktować jako pilną, zwłaszcza w środowiskach współdzielonych i kontenerowych. Nie jest to zdalny atak sam w sobie, ale po uzyskaniu lokalnego wykonania kodu daje bardzo mocny etap eskalacji. Najrozsądniejsza kolejność działań to: inwentaryzacja aktywnych kerneli, priorytet dla Kubernetes i CI/CD, aktualizacja pakietów jądra, restart hostów, tymczasowa blokada algif_aead tam, gdzie trzeba, oraz ograniczenie AF_ALG w profilach seccomp. W tym przypadku liczy się nie tylko załatanie, ale też ograniczenie powierzchni ataku na przyszłość.

Źródła i dalsza lektura

• Copy Fail — CVE-2026-31431
• Copy Fail: 732 Bytes to Root on Every Major Linux Distribution — Xint
• Fixes available for CVE-2026-31431 Copy Fail Linux Kernel Local Privilege Escalation Vulnerability — Canonical
• CVE-2026-31431: Copy Fail Linux kernel flaw lets local users gain root in seconds — Sysdig
• Security Advisory 2026-005: High Vulnerability in the Linux Kernel Copy Fail — CERT-EU