Copy Fail: 4 bajty, root i pilna lekcja dla administratorów Linuksa

29 kwietnia 2026 r. publicznie ujawniono CVE-2026-31431, lukę lokalnej eskalacji uprawnień w kernelu Linuksa, nazwaną Copy Fail. To nie jest kolejny błąd, który można spokojnie dopisać do backlogu aktualizacji na koniec miesiąca. W praktyce chodzi o podatność, która przy spełnieniu warunku lokalnego wykonania kodu pozwala przejść z nieuprzywilejowanego użytkownika do roota. Dla administratorów oznacza to natychmiastowy przegląd serwerów z kontami shellowymi, runnerów CI/CD, hostów buildowych, maszyn z kontenerami oraz węzłów Kubernetes.

Najważniejszy szczegół techniczny: Copy Fail dotyczy interfejsu kryptograficznego Linuksa dla przestrzeni użytkownika, konkretnie modułu algif_aead używanego przez AF_ALG. Badacze Xint Code opisali łańcuch wykorzystujący AF_ALG oraz splice(), który prowadzi do kontrolowanego zapisu 4 bajtów w page cache pliku możliwego do odczytu. Jeżeli celem jest binarka z bitem setuid, skutkiem może być wykonanie kodu jako root bez modyfikowania pliku na dysku.

Co dokładnie się wydarzyło

Według publicznej osi czasu luka została ujawniona 29 kwietnia 2026 r. Canonical opublikował 30 kwietnia 2026 r. komunikat dla Ubuntu, wskazując CVSS 3.1 na poziomie 7.8, czyli kategorię High. Tego samego dnia CERT-EU wydał advisory 2026-005, rekomendując priorytetowe działania dla węzłów Kubernetes i runnerów CI/CD, szczególnie tam, gdzie wykonywane są niezaufane workloady. 1 maja 2026 r. Microsoft Defender Security Research opisał ryzyko dla środowisk chmurowych i dystrybucji takich jak Ubuntu, Red Hat, SUSE oraz Amazon Linux.

W źródłach technicznych przewija się ważna informacja historyczna: problem ma korzenie w optymalizacji z 2017 r. dotyczącej operacji AEAD wykonywanych in-place. W dużym uproszczeniu optymalizacja spowodowała, że strony page cache mogły znaleźć się w strukturze traktowanej jako zapisywalny bufor docelowy. To właśnie ta właściwość została połączona z mechanizmem splice(), który przenosi dane między deskryptorami bez klasycznego kopiowania do przestrzeni użytkownika.

To istotne, bo nie mówimy o błędzie w jednej dystrybucji, jednej paczce ani jednym demonie systemowym. Podatność znajduje się w jądrze i w ścieżce, którą mogą osiągnąć lokalne procesy bez specjalnych uprawnień. Xint Code twierdzi, że przygotowany PoC działał na Ubuntu, Amazon Linux, RHEL i SUSE. Sysdig wskazał 30 kwietnia 2026 r. działające exploity m.in. dla Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 oraz SUSE 16.

Dlaczego Copy Fail jest groźne dla adminów, a nie tylko dla badaczy kernela

Klasyczna lokalna eskalacja uprawnień bywa bagatelizowana argumentem: „atakujący musi już mieć konto”. W 2026 r. to założenie jest coraz słabsze. W wielu środowiskach lokalny kod uruchamia się rutynowo: w pipeline’ach CI, w kontenerach buildowych, w platformach PaaS, na serwerach hostingowych, w środowiskach developerskich z wieloma kontami oraz w systemach wykonujących kod dostarczany przez klientów. Jeżeli taki kod może otworzyć socket AF_ALG, podatność przestaje być teoretyczna.

Najbardziej niewygodny element Copy Fail to page cache. Zwykłe narzędzia integralności, które porównują sumy kontrolne plików na dysku, mogą nie zobaczyć skutku ataku, ponieważ modyfikowana jest reprezentacja w pamięci, a nie trwały obraz pliku. Dla operatora oznacza to, że samo „sprawdźmy sha256sum /usr/bin/su” nie wystarczy jako pewny test bezpieczeństwa. Jeżeli na hoście doszło do wykorzystania podatności, należy traktować go jak system po eskalacji do roota, a nie jak maszynę z pojedynczym zmienionym plikiem.

Druga konsekwencja dotyczy kontenerów. Page cache jest współdzielony na poziomie hosta, dlatego scenariusze z kontenerami są szczególnie wrażliwe. Nawet jeżeli PoC dla konkretnego scenariusza container escape nie jest jeszcze powszechnie używany w danym środowisku, sam kierunek ataku jest jasny: lokalny kod w kontenerze może oddziaływać na zasoby jądra i pamięci podręcznej hosta. To uderza w modele, w których kontener jest traktowany jako wystarczająca granica izolacji dla kodu niezaufanego.

Które systemy są w grupie ryzyka

Na podstawie komunikatów z 30 kwietnia 2026 r. trzeba przyjąć konserwatywną zasadę: jeżeli host używa kernela z linii wywodzącej się z okresu po wprowadzeniu optymalizacji w 2017 r. i nie ma potwierdzonego patcha albo mitigacji dostawcy, powinien zostać uznany za potencjalnie podatny. Canonical podał, że podatność dotyczy wydań Ubuntu sprzed Resolute, czyli przed Ubuntu 26.04. CERT-EU wskazał, że Ubuntu 26.04 i późniejsze kernele nie są objęte tym problemem według dostępnych informacji z advisory.

W praktyce w pierwszej kolejności warto przejrzeć:

• serwery Ubuntu 20.04 LTS, 22.04 LTS i 24.04 LTS, szczególnie z kontami shellowymi lub kontenerami,
• instancje Amazon Linux 2023 uruchamiające workloady aplikacyjne i buildowe,
• środowiska RHEL, Rocky Linux, AlmaLinux i Oracle Linux, zwłaszcza z runnerami CI,
• hosty SUSE/SLES używane jako platforma kontenerowa,
• węzły Kubernetes, na których uruchamiane są workloady pochodzące od wielu zespołów lub klientów,
• serwery hostingowe, bastiony, środowiska laboratoryjne i maszyny developerskie z wieloma użytkownikami.

Jak sprawdzić ekspozycję na hoście

Pierwszy etap to ustalenie wersji kernela i paczek bezpieczeństwa. Na Ubuntu Canonical wskazał sprawdzenie aktualnie uruchomionego jądra, zainstalowanych obrazów kernela oraz wersji kmod, ponieważ mitigacja dystrybuowana jest także przez pakiet wyłączający problematyczny moduł.

uname -r

dpkg -l 'linux-image*' | grep '^ii'
dpkg -l kmod

lsmod | grep '^algif_aead' || true
modinfo algif_aead 2>/dev/null | head -n 20 || true

Na systemach z rodziny RHEL sensowny minimalny przegląd wygląda podobnie: ustalenie kernela, sprawdzenie advisory dostawcy i przygotowanie restartu lub livepatchingu, jeżeli jest dostępny w danym kanale wsparcia. Nie należy zakładać, że sam fakt używania dystrybucji enterprise rozwiązuje problem. Liczy się konkretna wersja pakietu kernela, status erraty i to, czy host faktycznie uruchomił zaktualizowane jądro po restarcie.

uname -r

rpm -qa 'kernel*' | sort
rpm -q kmod

dnf update --security
# po aktualizacji kernela zaplanuj restart i potwierdź uname -r po starcie

Mitigacja: patch, wyłączenie algif_aead i ograniczenie AF_ALG

Najlepszą odpowiedzią pozostaje aktualizacja kernela do wersji zawierającej poprawkę dostawcy. Jeżeli kernel jest już zaktualizowany, ale system nadal działa na starym jądrze, ryzyko pozostaje do momentu restartu albo skutecznego livepatcha. To częsty błąd w środowiskach serwerowych: menedżer pakietów pokazuje nowe paczki, a procesy i kernel nadal pracują na poprzednim kodzie.

Jeżeli aktualizacja kernela nie jest możliwa natychmiast, należy zastosować mitigacje zalecone przez dostawcę dystrybucji. W przypadku Ubuntu komunikat z 30 kwietnia 2026 r. mówi o mitigacji w kmod, która wyłącza dotknięty moduł. Ręczne blacklistowanie może pomóc w części środowisk, ale nie zastępuje oficjalnej poprawki i może nie działać identycznie, jeśli funkcjonalność jest wbudowana w kernel albo moduł jest już używany.

cat >/etc/modprobe.d/disable-algif-aead.conf <<'EOF'
blacklist algif_aead
install algif_aead /bin/false
EOF

modprobe -r algif_aead 2>/dev/null || true

# Ubuntu/Debian, jeśli initramfs zawiera konfigurację modułów:
update-initramfs -u

# RHEL/SUSE/Fedora, zależnie od dystrybucji:
dracut -f

Dla kontenerów i pipeline’ów krytyczne jest ograniczenie możliwości tworzenia socketów AF_ALG. CERT-EU rekomenduje blokowanie tworzenia takich socketów przez seccomp w workloadach kontenerowych i pipeline’ach, niezależnie od statusu patchowania. To rozsądne jako dodatkowa warstwa obrony, bo exploit zaczyna się od dostępu do interfejsu AF_ALG. W Kubernetes warto przejrzeć profile seccomp przypisane do podów, a w Dockerze i Podmanie upewnić się, że workloady nie działają niepotrzebnie z profilem unconfined.

Monitoring: czego szukać w logach i runtime security

Detekcja Copy Fail nie powinna opierać się wyłącznie na sumach kontrolnych plików. Warto szukać nietypowego użycia AF_ALG, wywołań splice() w procesach, które nie powinny dotykać kryptograficznego API kernela, oraz niespodziewanych egzekucji binarek setuid połączonych z aktywnością procesów buildowych lub kontenerowych. Jeżeli używany jest Falco, Sysdig, auditd albo eBPF-owy sensor runtime security, to dobrym kierunkiem jest reguła na tworzenie socketu z rodziną AF_ALG.

# auditd: AF_ALG to 38 dziesiętnie, czyli 0x26; audit zapisuje argumenty jako hex
auditctl -a always,exit -F arch=b64 -S socket -F a0=26 -k af_alg_socket

auditctl -l | grep af_alg_socket
ausearch -k af_alg_socket

Nie jest to pełna blokada, ale daje sygnał operacyjny. W typowej aplikacji webowej, workerze CI albo kontenerze buildowym bez specjalnych wymagań kryptograficznych pojawienie się AF_ALG powinno wzbudzić zainteresowanie. Dla zespołów DevOps ważne jest też odróżnienie obserwacji od prewencji: auditd pomoże zobaczyć próbę, seccomp może ją zablokować, a poprawiony kernel usuwa klasę błędu.

Plan działania dla zespołu administracyjnego

Najbardziej praktyczny scenariusz na 4 maja 2026 r. to połączenie inwentaryzacji, krótkoterminowej mitigacji i zaplanowanego patchowania. Nie ma sensu czekać na „okno miesięczne”, jeżeli host uruchamia niezaufany kod. Priorytet powinny mieć maszyny, na których atakujący może uzyskać lokalne wykonanie kodu nawet bez klasycznego konta użytkownika: runner CI, środowisko testów pull requestów, platforma kontenerowa, serwer hostingowy, bastion z wieloma kontami oraz maszyny udostępniane zespołom developerskim.

1. Zrób listę hostów z kernelem Linuksa i oznacz systemy z kontenerami, CI/CD oraz wieloma użytkownikami.
2. Sprawdź advisory konkretnego dostawcy dystrybucji i wersję aktualnie uruchomionego kernela przez uname -r.
3. Zastosuj oficjalną aktualizację kernela albo mitigację kmod, jeżeli jest wskazana przez dostawcę.
4. Wymuś restart tam, gdzie kernel został zaktualizowany, i potwierdź wersję po starcie.
5. Dla kontenerów zablokuj AF_ALG przez seccomp, szczególnie w workloadach niezaufanych.
6. Dodaj monitoring użycia AF_ALG i przejrzyj logi z okresu od 29 kwietnia 2026 r.

Praktyczne podsumowanie

Copy Fail jest groźne, bo łączy prosty warunek wejściowy — lokalne wykonanie kodu — z wysoką nagrodą: rootem na hoście. Najważniejsze działania to aktualizacja kernela, sprawdzenie realnie uruchomionej wersji po restarcie, zastosowanie mitigacji dostawcy oraz blokada AF_ALG w kontenerach i pipeline’ach. Jeżeli utrzymujesz Kubernetes, CI/CD albo serwery z wieloma użytkownikami, potraktuj CVE-2026-31431 jako incydent operacyjny, a nie zwykłą pozycję w raporcie podatności.

Źródła i dalsza lektura

• Ubuntu: Fixes available for CVE-2026-31431 Copy Fail Linux Kernel Local Privilege Escalation Vulnerability
• Xint Code: Copy Fail — 732 Bytes to Root on Every Major Linux Distribution
• CERT-EU Security Advisory 2026-005: High Vulnerability in the Linux Kernel Copy Fail
• Microsoft Security Blog: CVE-2026-31431 Copy Fail vulnerability enables Linux root privilege escalation across cloud environments
• Sysdig: CVE-2026-31431 Copy Fail Linux kernel flaw lets local users gain root in seconds