29 kwietnia 2026 r. badacze z Xint Code publicznie opisali CVE-2026-31431, nazwaną Copy Fail. To podatność typu local privilege escalation w jądrze Linuksa, która dotyczy interfejsu kryptograficznego AF_ALG, modułu algif_aead i ścieżki wykorzystującej splice(). W praktyce oznacza to, że nieuprzywilejowany lokalny użytkownik może doprowadzić do kontrolowanego zapisu 4 bajtów w page cache pliku, a następnie użyć tego efektu do uzyskania uprawnień roota.
Brzmi jak niszowy błąd w subsystemie crypto? Dla administratora Linuksa to jest właśnie najgorszy typ podatności: nie wymaga otwartego portu, nie wygląda jak klasyczny zdalny exploit, a mimo to może być ostatnim krokiem w przejęciu hosta po wcześniejszym zdobyciu konta użytkownika, uruchomieniu złośliwego joba CI albo wejściu do kontenera. CERT-EU opublikował własny advisory 30 kwietnia 2026 r., a NVD wskazuje, że luka trafiła do katalogu CISA Known Exploited Vulnerabilities 1 maja 2026 r. z terminem wymaganej reakcji 15 maja 2026 r. dla objętych nim środowisk federalnych w USA.
Co dokładnie się wydarzyło
Copy Fail jest błędem logicznym w ścieżce AEAD jądra Linuksa. AF_ALG pozwala procesom użytkownika korzystać z kernelowego API kryptograficznego przez sockety. Z kolei splice() pozwala przenosić dane między deskryptorami bez klasycznego kopiowania, m.in. przez przekazywanie referencji do stron page cache. Problem powstał na styku tych mechanizmów: dane z pliku mogły znaleźć się w scatterlist, która w pewnym momencie była traktowana jak bufor zapisywalny.
Według opisu Xint Code, źródłem błędu była optymalizacja dodana w 2017 r. w algif_aead, która przełączyła operacje AEAD na tryb in-place. Sama optymalizacja miała sens wydajnościowy, ale w połączeniu z zachowaniem algorytmu authencesn(hmac(sha256),cbc(aes)) i wejściem dostarczonym przez splice() prowadziła do zapisu poza oczekiwany obszar. Ten zapis trafiał nie na zwykły bufor procesu, lecz do page cache pliku czytelnego przez użytkownika.
Najważniejszy detal operacyjny: modyfikowany jest cache w pamięci, a nie plik na dysku. Oznacza to, że proste porównanie sum kontrolnych pliku z dysku może niczego nie wykazać, bo dyskowa kopia binarki pozostaje niezmieniona. Jeżeli jednak cache zawiera zmodyfikowaną wersję programu z bitem setuid, kolejne wykonanie takiego programu może użyć już zmienionej zawartości w pamięci.
Dlaczego to jest groźne dla adminów i DevOpsów
CVE-2026-31431 nie jest zdalnym RCE samym w sobie. Atakujący musi mieć lokalny punkt zaczepienia: konto shellowe, proces działający na hoście, możliwość uruchomienia kodu w jobie CI/CD albo kontenerze na podatnym jądrze. W realnych środowiskach to wcale nie jest niski próg. Współczesna infrastruktura często uruchamia obcy kod: testy pull requestów, buildy pakietów, workloady tenantskie, notebooki, zadania analityczne, ephemeral runnery i kontenery developerskie.
Microsoft w swojej analizie podkreślił, że udane wykorzystanie daje pełną eskalację do roota i może ułatwiać container breakout, lateral movement oraz kompromitację środowisk współdzielonych. Red Hat ocenił problem jako Important i opisał ryzyko dla lokalnego użytkownika mogącego uzyskać uprawnienia administratora. Canonical 30 kwietnia 2026 r. wskazał, że podatność dotyczy wydań Ubuntu sprzed 26.04 Resolute, a tymczasowa mitygacja w Ubuntu polegała na wyłączeniu dotkniętego modułu przez pakiet kmod.
Najbardziej narażone klasy systemów to:
- współdzielone serwery shellowe i bastiony — każdy użytkownik z kontem lokalnym staje się potencjalnym punktem eskalacji;
- self-hosted runnery CI/CD — złośliwy pull request może przejść od zwykłego joba do roota na runnerze;
- węzły Kubernetes — szczególnie tam, gdzie uruchamiany jest kod wielu zespołów lub klientów na tym samym jądrze;
- platformy sandbox i notebooki — usługi uruchamiające kod użytkowników w kontenerach lub lekkich izolacjach;
- serwery po incydencie webowym — jeżeli napastnik uzyskał już usera przez aplikację, Copy Fail może być kolejnym etapem.
Jak sprawdzić systemy w praktyce
Pierwszym krokiem nie jest uruchamianie publicznego PoC na produkcji. To podatność ingerująca w page cache i celująca w setuid binaries, więc testy eksploatacyjne powinny być ograniczone do odizolowanego labu. Na produkcji trzeba zacząć od inwentaryzacji jąder, dystrybucji i klas workloadów.
uname -a
uname -r
cat /etc/os-release
# Debian/Ubuntu: sprawdzenie zainstalowanych obrazów jądra
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'
# RHEL/Rocky/Alma/Fedora: lista pakietów kernel
rpm -q kernel kernel-core 2>/dev/null || trueNVD wylicza wiele zakresów podatnych wersji jądra, m.in. linie od 4.14 do wersji z poprawkami w odpowiednich gałęziach stable. W praktyce nie należy opierać decyzji wyłącznie na numerze uname -r, bo dystrybucje backportują poprawki bezpieczeństwa do starszych linii. Bezpieczniejsza metoda to sprawdzenie advisory konkretnego vendora: Ubuntu Security Notices, Red Hat CVE page, SUSE advisories, Amazon Linux Security Center, Debian Security Tracker albo repozytorium dostawcy appliance.
Dla środowisk kontenerowych ważne jest rozróżnienie: podatne jest jądro hosta, nie obraz kontenera. Aktualizacja paczek w kontenerze nie usuwa problemu, jeżeli node dalej działa na podatnym kernelu. W Kubernetes trzeba więc patrzeć na node pool, AMI/base image węzłów, konfigurację managed node groups i okna restartów po aktualizacji kernela.
Patchowanie: co robić 29 maja 2026 r.
Najważniejsza rekomendacja jest prosta: zainstalować kernel od dostawcy dystrybucji, który zawiera poprawkę dla CVE-2026-31431, a następnie zrestartować system lub użyć zatwierdzonego mechanizmu livepatch, jeśli organizacja go stosuje. Samo pobranie pakietu kernela nie wystarczy, jeżeli host nadal pracuje na starej wersji widocznej w uname -r.
# Ubuntu/Debian
sudo apt update
sudo apt full-upgrade
sudo reboot
# RHEL/Rocky/Alma
sudo dnf update kernel kernel-core
sudo reboot
# Po restarcie
uname -r
systemctl --failedW flotach produkcyjnych warto zacząć od systemów, na których istnieje realna możliwość lokalnego wykonania kodu przez mniej zaufanych użytkowników. W praktyce priorytetem powinny być runnery CI, hosty developerskie, klastry Kubernetes, bastiony, serwery z kontami wielu administratorów oraz hosty pośrednie używane do automatyzacji. Jednoużytkownikowa stacja robocza jest mniej krytyczna, ale nie jest odporna: malware uruchomione jako zwykły użytkownik może potraktować Copy Fail jako eskalację po infekcji.
Mitygacje, gdy restart nie jest możliwy
Jeżeli okno restartowe jest zablokowane, można ograniczać powierzchnię ataku. Xint Code i Canonical wskazywały blokowanie algif_aead jako tymczasową mitygację tam, gdzie moduł jest ładowalny. Red Hat opisał także warianty z parametrami bootowania, gdy funkcje są wbudowane w kernel. Trzeba jednak pamiętać, że mitygacja może wpływać na aplikacje nietypowo korzystające z AF_ALG, np. przez jawnie skonfigurowany silnik kryptograficzny.
# Tymczasowe zablokowanie ładowalnego modułu algif_aead
printf 'install algif_aead /bin/false\n' | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo modprobe -r algif_aead 2>/dev/null || true
# Szybki rekonesans użycia AF_ALG
ss -xa | grep -i alg || true
sudo lsof 2>/dev/null | grep AF_ALG || trueW kontenerach i sandboxach sensowną warstwą obrony jest też blokowanie tworzenia socketów AF_ALG przez seccomp, o ile nie psuje to oczekiwanych workloadów. Nie zastępuje to poprawki kernela, ale zmniejsza ryzyko na hostach, na których przez kilka godzin lub dni nie można przeprowadzić rebootu. Warto również ograniczyć dostęp do oc debug, uprzywilejowanych podów, hostPath, kontenerów z dodatkowymi capabilities oraz self-hosted runnerów wykonujących kod spoza zaufanego repozytorium.
Co monitorować po stronie detekcji
Copy Fail nie zostawia klasycznego śladu zapisu do pliku, bo istotna modyfikacja zachodzi w page cache. To ogranicza skuteczność prostych kontroli integralności opartych tylko o odczyt z dysku. Warto zamiast tego patrzeć na zachowania: nietypowe użycie AF_ALG przez procesy użytkownika, wykonywanie setuid binaries po nietypowej sekwencji wywołań, uruchomienia su, sudo lub innych setuid programów przez konta techniczne oraz nagłe pojawienie się procesów roota z nietypowym rodzicem.
Dla administratorów praktyczny trop to korelacja zdarzeń: job CI uruchamia proces Pythona, proces korzysta z socketów AF_ALG lub splice(), a następnie pojawia się shell z UID 0. Nie każda organizacja zbiera syscall telemetry na Linuksie, ale tam, gdzie działają eBPF-based runtime security, auditd, Falco, osquery albo EDR z obsługą Linuksa, warto sprawdzić, czy dostawca dodał reguły dla CVE-2026-31431.
Szerszy wniosek: kernel jest granicą zaufania dla kontenerów
Copy Fail przypomina o rzeczy, którą łatwo zignorować w codziennej pracy z Dockerem i Kubernetesem: kontenery współdzielą jądro hosta. Jeżeli podatność znajduje się w kernelu, separacja namespace, cgroups i obrazów kontenerów może nie wystarczyć. Dotyczy to zwłaszcza mechanizmów, które są dostępne dla nieuprzywilejowanego userspace i nie były projektowane z myślą o masowym uruchamianiu obcego kodu w tysiącach kontenerów.
Dla zespołów DevOps to dobry moment, aby przejrzeć politykę patchowania kernelowego. Cykliczne aktualizacje raz na kwartał są zbyt wolne dla podatności z publicznym PoC i wpisem w KEV. Potrzebna jest ścieżka awaryjna: szybka identyfikacja node pooli, canary reboot, drain węzłów, wymiana obrazów bazowych, potwierdzenie wersji po restarcie i raport zamknięcia ryzyka. Bez tego nawet dobrze zarządzany klaster może przez tygodnie działać na podatnym jądrze.
Praktyczne podsumowanie
Do wykonania: zinwentaryzuj wersje jąder, sprawdź advisory swojego vendora, załataj kernel i potwierdź aktywną wersję po restarcie. Najpierw obsłuż Kubernetes, CI/CD, bastiony i hosty współdzielone. Jeżeli restart musi poczekać, rozważ blokadę algif_aead lub AF_ALG przez seccomp oraz ograniczenie uruchamiania niezaufanego kodu. Copy Fail nie jest tylko ciekawostką z subsystemu crypto; to podatność, która pokazuje, że lokalny dostęp na Linuksie nadal może bardzo szybko stać się pełnym rootem.
Źródła i dalsza lektura
- Xint Code: Copy Fail: 732 Bytes to Root on Linux
- CERT-EU Security Advisory 2026-005: High Vulnerability in the Linux Kernel "Copy Fail"
- Canonical: Fixes available for CVE-2026-31431 Copy Fail
- Red Hat: RHSB-2026-002 Cryptographic Subsystem Privilege Escalation
- Microsoft Security Blog: CVE-2026-31431 Copy Fail vulnerability enables Linux root privilege escalation