CVE-2026-31431 („Copy Fail”) – groźna podatność w jądrze Linux. Co się stało i jak się zabezpieczyć

Pod koniec kwietnia 2026 r. publicznie ujawniono groźną podatność w jądrze Linuksa oznaczoną jako CVE-2026-31431, nazwaną Copy Fail. To luka typu local privilege escalation, czyli taka, która pozwala użytkownikowi mającemu już lokalny dostęp do systemu podnieść uprawnienia do roota. Problem dotyczy mechanizmu algif_aead w interfejsie AF_ALG, czyli użytkownikowego frontendu do kryptografii jądra. CERT-EU podaje, że luka dotyczy mainstreamowych dystrybucji z kernelami budowanymi od 2017 r., a publiczny proof-of-concept jest już dostępny.

To nie jest podatność „zdalna po samym porcie”, ale nie należy jej bagatelizować. W praktyce jest szczególnie groźna wszędzie tam, gdzie na hoście uruchamiane są niezaufane workloady, wielu użytkowników, kontenery, CI/CD runnery albo usługi dające shell lub możliwość wykonania lokalnego kodu. CERT-EU wprost wskazuje Kubernetes nodes i CI/CD runners jako priorytet do natychmiastowej mitigacji.

Co to jest CVE-2026-31431

CVE-2026-31431 to błąd logiczny w jądrze Linux, w ścieżce crypto: algif_aead, który – po połączeniu z splice() – może dać nieuprzywilejowanemu użytkownikowi kontrolowany zapis 4 bajtów do strony page cache pliku, który jest dla niego czytelny. W praktyce pozwala to modyfikować w pamięci podręcznej np. binarkę setuid i uzyskać roota, mimo że sam plik na dysku nie zostaje klasycznie nadpisany. Tak opisują to badacze Xint, a CERT-EU potwierdza ten mechanizm w swoim advisory.

NVD i CVE record opisują problem jako błąd naprawiony przez zmianę „crypto: algif_aead – Revert to operating out-of-place”, czyli w uproszczeniu: cofnięcie wadliwej optymalizacji wprowadzonej wcześniej do tej ścieżki kodu. Źródłem problemu był commit z 2017 r. 72548b093ee3, a fix upstreamowy to commit a664bf3d603d.

Co dokładnie się stało

Podatność została publicznie nagłośniona 29 kwietnia 2026 r. Xint opisuje ją jako prostą, przenośną i wyjątkowo praktyczną: ten sam krótki skrypt w Pythonie miał działać na testowanych dużych dystrybucjach, bez wyścigów, bez kruchych timingów i bez przebudowy pod każdy system osobno. CERT-EU podaje, że publiczne ujawnienie nastąpiło 29 kwietnia, a łatka w mainline była już wcześniej – 1 kwietnia 2026 r.

Badacze podkreślają jeszcze jedną nieprzyjemną cechę: modyfikacja dotyczy page cache, więc standardowe porównanie sum kontrolnych pliku na dysku może nic nie wykazać, bo uszkodzona jest wersja „czytana” z pamięci, niekoniecznie sama zawartość na nośniku. To czyni incydent trudniejszym do intuicyjnego zauważenia.

Jak działa podatność

W praktyce luka wynika z błędnego potraktowania stron page cache jako zapisywalnego celu podczas operacji AEAD wykonywanej przez AF_ALG. CERT-EU opisuje to tak: przez połączenie operacji AF_ALG z splice() nieuprzywilejowany użytkownik może uzyskać kontrolowany zapis 4 bajtów do page-cache-backed page. Xint dopowiada, że problem dotyczy ścieżki authencesn, która traktuje określony bufor jak operację in-place i dokonuje zapisu jeszcze przed ostatecznym błędem walidacji taga.

Nie trzeba tu znać wszystkich szczegółów kryptograficznych, żeby zrozumieć sedno: użytkownik lokalny może przekuć błąd logiczny w jądrze na zapis do pamięci podręcznej pliku i finalnie na roota. Ubuntu określa to wprost jako „trivial local privilege escalation”.

Kogo dotyczy problem

Najprostsza odpowiedź brzmi: bardzo wielu systemów Linux z kernelami od 2017 r. do czasu wdrożenia poprawek vendorów. CERT-EU napisał wprost, że problem dotyczy mainstreamowych dystrybucji shipping kernels built since 2017, a badacze bezpośrednio zweryfikowali podatność m.in. na Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 i SUSE 16.

Ubuntu podało, że problem dotyczy wszystkich wspieranych wydań przed 26.04 Resolute, a jako mitigację dostarczyło aktualizację kmod, która blokuje moduł, zanim dotrą finalne poprawki kernela. Amazon Linux w swoim trackerze pokazywał na moment sprawdzania status Pending Fix dla Amazon Linux 2 i Amazon Linux 2023. CloudLinux informował 30 kwietnia 2026 r., że poprawki i livepatch są jeszcze przygotowywane dla wersji podatnych.

Czy to jest zdalne czy lokalne

To jest lokalna eskalacja uprawnień. Samo istnienie hosta w internecie nie oznacza jeszcze, że ktoś z zewnątrz od razu wykorzysta CVE-2026-31431 po TCP/443 czy SSH. Ale jeśli napastnik ma już jakikolwiek foothold, konto użytkownika, możliwość uruchomienia procesu, wejście przez aplikację webową, CI runnera, kontener albo inny punkt wykonania kodu, wtedy ta luka może być kolejnym krokiem do pełnego przejęcia systemu. Ubuntu i CERT-EU opisują ją właśnie jako local privilege escalation.

W środowiskach kontenerowych problem robi się jeszcze poważniejszy, bo badacze wskazują, że page cache jest współdzielony przez host, co daje potencjał do scenariuszy cross-container / container escape. Ubuntu również zaznacza, że w deploymentach kontenerowych podatność może ułatwiać escape scenarios.

Jak sprawdzić, czy podatność nas dotyczy

Najuczciwsza odpowiedź jest taka: najpierw sprawdź kernel i advisory swojego vendora, a dopiero potem baw się w szczegóły techniczne. Sam numer kernela nie zawsze wystarczy, bo dystrybucje backportują poprawki bez spektakularnej zmiany „głównej” wersji. Ubuntu wprost zaleca porównać działający kernel i zainstalowane pakiety z własnym advisory.

1. Sprawdź wersję uruchomionego kernela

uname -r

Na Ubuntu można też wypisać zainstalowane obrazy kernela:

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

Canonical zaleca właśnie takie sprawdzenie i porównanie z tabelą statusu dla danej gałęzi.

2. Sprawdź advisory swojej dystrybucji

Dla bieżącego stanu na 30 kwietnia 2026 r.:

• Ubuntu ma publiczną stronę CVE i osobny wpis z mitigacją.
• Amazon Linux pokazywał status Pending Fix.
• Debian ma wpis trackera CVE.
• SUSE ma stronę CVE.
• Red Hat publikuje CVE page dla tej luki.

3. Sprawdź, czy algif_aead jest modułem czy built-in

To ważne, bo od tego zależy sens doraźnej mitigacji. CloudLinux ostrzega, że na części systemów z rodziny RHEL algif_aead jest wbudowane w kernel (CONFIG_CRYPTO_USER_API_AEAD=y), więc workaround oparty o modprobe.d i rmmod nie zadziała. Możesz to sprawdzić tak:

modinfo algif_aead | grep filename

Jeśli zobaczysz (builtin), to reguła install algif_aead /bin/false nie zablokuje tego komponentu.

4. Sprawdź, czy mitigacja jest aktywna

Na systemach, gdzie zastosowano workaround z parametrem kernela:

cat /proc/cmdline

albo:

grubby --info=ALL | grep initcall_blacklist

Jeśli aktywny wpis zawiera initcall_blacklist=algif_aead_init, to dana mitigacja została ustawiona. Taką weryfikację opisuje CloudLinux, a skuteczność potwierdzono też w dyskusji na oss-security dla Rocky Linux 9.7.

5. Sprawdź, czy ktoś realnie korzysta z AF_ALG

Strona copy.fail sugeruje, by w razie wątpliwości sprawdzić użycie AF_ALG m.in. przez lsof lub ss -xa. To bardziej check kompatybilności niż check podatności, ale może pomóc ocenić skutki uboczne wyłączenia tej ścieżki.

Co trzeba zrobić, żeby się zabezpieczyć

Najważniejsza zasada: zaktualizować kernel do wersji z poprawką vendora albo zastosować vendorową mitigację natychmiast, jeśli poprawka nie jest jeszcze dostępna. CERT-EU napisał, że 30 kwietnia 2026 r. wiele dystrybucji jeszcze nie miało wypchniętych gotowych paczek, mimo że fix upstreamowy był już w mainline.

Ścieżka 1: właściwa poprawka kernela

Upstreamowe poprawki zostały powiązane z gałęziami:

• 6.18.22,
• 6.19.12,
• 7.0,
  przy czym issue wprowadzono w 4.14 przez commit 72548b093ee3. Informacja ta pojawiła się w wątku oss-security odnoszącym się do komunikatu kernel CVE team.

Uwaga praktyczna: na dystrybucjach enterprise nie należy patrzeć wyłącznie na „czy mam 6.18.22”, tylko na konkretny vendor package / errata / advisory, bo backport może być już w kernelsach z innym nazewnictwem. Ubuntu, CloudLinux i Amazon opisują to po swojemu, a nie jako czystą numerację upstreamu.

Ścieżka 2: doraźna mitigacja przed patchem

Tu trzeba uważać, bo nie ma jednego uniwersalnego przepisu dla wszystkich distro.

Ubuntu

Canonical wydał aktualizację kmod, która blokuje moduł algif_aead, a jeśli nie chcesz czekać na pełny update kernela, zaleca:

sudo apt update && sudo apt upgrade

albo przynajmniej:

sudo apt update && sudo apt install --only-upgrade kmod

W wariancie ręcznym Ubuntu podaje też:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null
grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"
sudo reboot

Canonical zaznacza przy tym, że wyłączenie modułu może wymagać rebootu, a niektóre aplikacje mogą potrzebować fallbacku do userspace crypto.

RHEL-family / Alma / Rocky / CloudLinux

Tu modprobe-based workaround może być fałszywą ochroną, jeśli algif_aead jest built-in. CloudLinux zaleca w takim przypadku parametr kernela:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Weryfikacja:

sudo grubby --info=ALL | grep initcall_blacklist

Po instalacji poprawionego kernela można to cofnąć:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Ta metoda została też potwierdzona testowo w wątku oss-security dla Rocky Linux.

Ścieżka 3: ograniczenie ryzyka w kontenerach i workloadach nieufnych

Strona copy.fail rekomenduje, aby dla untrusted workloads blokować tworzenie socketów AF_ALG przez seccomp, niezależnie od stanu patcha. To dobra warstwa dodatkowa dla kontenerów, sandboxów i CI.

Czy wyłączenie AF_ALG coś zepsuje

W większości klasycznych zastosowań hostingowych – raczej nie. CloudLinux wskazuje, że dm-crypt/LUKS, kTLS, IPsec, SSH oraz domyślne buildy OpenSSL/GnuTLS nie polegają na AF_ALG i pozostają niezmienione. Strona copy.fail podaje podobną listę rzeczy, których wyłączenie AF_ALG nie powinno dotknąć.

Ale trzeba zachować ostrożność. Ubuntu uczciwie uprzedza o ryzyku regresji, a w dyskusji na oss-security zwrócono uwagę, że niektóre aplikacje i biblioteki – m.in. libkcapi i pewne komponenty korzystające z AEAD przez AF_ALG – mogą być dotknięte ubocznie. Czyli: mitigacja jest potrzebna, ale po wdrożeniu warto sprawdzić krytyczne workloady.

Sekcja praktyczna

Szybka checklista dla administratora

1. Sprawdź uname -r i advisory vendora. Sama „główna wersja” kernela to za mało.
2. Zweryfikuj, czy algif_aead jest modułem czy built-in. To decyduje o skuteczności workaroundu.
3. Na Ubuntu: zainstaluj aktualizacje, a jeśli trzeba, kmod jako mitigację.
4. Na RHEL-family / Alma / Rocky / CloudLinux: rozważ initcall_blacklist=algif_aead_init, jeśli poprawiony kernel nie jest jeszcze dostępny.
5. Po mitigacji zrób reboot, jeśli to wymagane, i zweryfikuj stan.
6. Na hostach z kontenerami i CI: potraktuj temat priorytetowo, bo ryzyko jest wyższe.
7. Po załataniu sprawdź kompatybilność aplikacji, jeśli używają nietypowych ścieżek kryptograficznych opartych o AF_ALG.

Minimalny zestaw komend diagnostycznych

uname -r
modinfo algif_aead | grep filename
cat /proc/cmdline
grep -qE '^algif_aead ' /proc/modules && echo "algif_aead loaded" || echo "algif_aead not loaded"

Te polecenia same w sobie nie dają pełnej odpowiedzi „na pewno bezpieczny / na pewno podatny”, ale pozwalają szybko ustalić punkt wyjścia i dobrać właściwą ścieżkę działania na podstawie advisory dostawcy.

Garść ciekawostek

• CERT-EU nadał tej luce rangę wysoką i zalecił natychmiastową mitigację, mimo że to „tylko” local privilege escalation. Powód jest prosty: exploit jest publiczny i prosty w użyciu.
• Badacze Xint podkreślają, że problem nie wymaga wyścigów ani kruchych timingów, w przeciwieństwie do niektórych historycznych bugów kernelowych.
• Ujawnienie nazwano Copy Fail, a porównania do Dirty COW czy Dirty Pipe pojawiają się właśnie dlatego, że znów chodzi o nieintuicyjny zapis związany z page cache.
• CVE zostało przydzielone 22 kwietnia 2026 r., a publiczne disclosure nastąpiło 29 kwietnia 2026 r.
• Canonical podkreślił, że Ubuntu 26.04 Resolute nie jest podatne, a wcześniejsze wspierane wydania są objęte problemem.

Podsumowanie

CVE-2026-31431 to bardzo poważna podatność lokalnej eskalacji uprawnień w jądrze Linux. Nie jest to „remote RCE z internetu po jednym pakiecie”, ale w realnych środowiskach wieloużytkownikowych, kontenerowych i hostingowych jej znaczenie jest duże, bo publiczny exploit już istnieje, a droga do roota jest praktyczna i powtarzalna.

Najważniejsze działanie jest proste: sprawdź advisory swojej dystrybucji, wdroż poprawkę kernela albo właściwą mitigację vendora i nie zakładaj, że jeden workaround działa wszędzie tak samo. W tej luce najgorsze, co można zrobić, to odfajkować „coś tam wrzuciłem do modprobe.d”, gdy na danym systemie algif_aead jest wbudowane w kernel i nadal działa jak gdyby nigdy nic.

Źródła

1. CERT-EU, High Vulnerability in the Linux Kernel (“Copy Fail”).
2. NVD, CVE-2026-31431.
3. CVE.org, CVE Record: CVE-2026-31431.
4. Ubuntu Security, CVE-2026-31431.
5. Ubuntu Blog, Fixes available for CVE-2026-31431 (Copy Fail).
6. Xint, Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.
7. copy.fail, Disclosure / FAQ / mitigation notes.
8. oss-security, CVE-2026-31431 discussion and fixed upstream branches.
9. Amazon Linux Security Center, CVE-2026-31431.
10. CloudLinux Blog, CVE-2026-31431 (Copy Fail): Mitigation and Upcoming Patches.

Autor: Redakcja youITcare · AI-Assisted
Artykuł opracowany przy wsparciu narzędzi sztucznej inteligencji, pod redakcyjnym nadzorem zespołu youITcare.