Copy Fail w jądrze Linuksa: lokalny błąd, który zmienia zwykłego użytkownika w roota

29 kwietnia 2026 r. publicznie ujawniono CVE-2026-31431, podatność znaną jako Copy Fail. To nie jest kolejny niszowy błąd w mało używanym sterowniku. Chodzi o lokalną eskalację uprawnień w jądrze Linuksa, w obszarze kryptograficznego interfejsu użytkownika AF_ALG, konkretnie w module algif_aead. W praktyce oznacza to, że proces działający jako nieuprzywilejowany użytkownik może na niezałatanym hoście uzyskać uprawnienia roota.

Sprawa jest istotna dla administratorów, zespołów platformowych i DevOps nie tylko dlatego, że mówimy o jądrze Linuksa. Ważniejszy jest kontekst operacyjny: współczesne serwery bardzo często uruchamiają obce lub częściowo niezaufane workloady. Kontenery, build runnery, środowiska testowe, notebooki ML, automatyzacje IaC i krótkotrwałe joby CI/CD powodują, że „lokalny użytkownik” nie zawsze oznacza człowieka z kontem SSH. Często oznacza proces, pipeline albo pod z ograniczonymi uprawnieniami, który po eskalacji staje się problemem całej maszyny.

Co dokładnie się wydarzyło

Copy Fail został opisany jako podatność typu local privilege escalation o wysokiej istotności. NVD klasyfikuje CVE-2026-31431 z wektorem lokalnym i CVSS 3.1 7.8, a wpis NVD wskazuje również obecność podatności w katalogu CISA Known Exploited Vulnerabilities z datą dodania 1 maja 2026 r. oraz terminem wymaganych działań 15 maja 2026 r. To ważny sygnał priorytetyzacyjny: jeżeli system figuruje w KEV, nie jest to już wyłącznie teoretyczny problem z listy mailingowej kernela.

Technicznie błąd dotyczy algif_aead, czyli części userspace crypto API dostępnej przez gniazda AF_ALG. AEAD oznacza Authenticated Encryption with Associated Data, a więc rodzinę mechanizmów kryptograficznych używanych m.in. wtedy, gdy szyfrowanie ma jednocześnie zapewniać integralność danych. Według opisu CERT-EU problem pochodzi z optymalizacji operacji „in-place” wprowadzonej w 2017 r. i może prowadzić do kontrolowanego zapisu czterech bajtów do strony page cache powiązanej z plikiem możliwym do odczytu.

Brzmi to nisko poziomowo, ale skutek jest bardzo praktyczny. Jeżeli atakujący jest w stanie precyzyjnie wpłynąć na page cache pliku wykonywalnego z bitem setuid, może doprowadzić do uruchomienia kodu z podwyższonymi uprawnieniami. W publicznych opisach technicznych jako przykład pojawia się celowanie w binaria takie jak /usr/bin/su. To nie wymaga zdalnego RCE w demonie sieciowym, ale wymaga jakiejkolwiek możliwości wykonania kodu lokalnie jako zwykły użytkownik lub workload.

Dlaczego admin Linuksa powinien potraktować to priorytetowo

W klasycznym modelu bezpieczeństwa „local privilege escalation” bywa odkładane niżej niż zdalne wykonanie kodu. W 2026 r. to podejście jest coraz bardziej ryzykowne. Na hostach chmurowych i w klastrach Kubernetes granica między lokalnym a zdalnym bywa cienka: wystarczy podatna aplikacja webowa, źle odizolowany runner CI, konto deweloperskie z dostępem do bastiona albo zadanie uruchamiane z artefaktu pochodzącego z pull requesta.

Microsoft w analizie z 1 maja 2026 r. wskazał, że problem dotyczy wielu dużych dystrybucji, w tym Red Hat, SUSE, Ubuntu i AWS Linux, oraz że ma znaczenie dla workloadów chmurowych i klastrów Kubernetes. Canonical potwierdził, że w przypadku Ubuntu podatność dotyczy wydań przed Ubuntu 26.04 „Resolute”, a zespół Ubuntu Security Team opublikował mitygację w pakiecie kmod, która blokuje ładowanie podatnego modułu algif_aead.

Najważniejsze ryzyka operacyjne są następujące:

• Serwery wieloużytkownikowe — jump hosty, serwery deweloperskie, maszyny laboratoryjne i środowiska HPC, gdzie wielu użytkowników ma możliwość uruchamiania własnego kodu.
• Kubernetes i platformy kontenerowe — szczególnie węzły worker uruchamiające obrazy spoza w pełni kontrolowanego registry, joby testowe, buildy lub workloady wielu zespołów.
• CI/CD — runnery GitLaba, GitHuba, Jenkinsa czy Buildkite, które wykonują kod z repozytoriów lub z pull requestów.
• Środowiska AI/ML — notebooki Jupyter, serwery inferencyjne, klastry GPU i eksperymenty badawcze, gdzie użytkownicy często mają dużą swobodę instalowania zależności i uruchamiania skryptów.
• Hosting i edge — systemy z wieloma tenantami, panele hostingowe, kontenery aplikacyjne klientów oraz urządzenia z długim cyklem aktualizacji kernela.

Jak sprawdzić ekspozycję na hoście

Pierwszym krokiem nie powinno być paniczne restartowanie całej floty, tylko szybka inwentaryzacja. Trzeba ustalić wersję kernela, dystrybucję, dostępność aktualizacji bezpieczeństwa oraz to, czy algif_aead jest aktualnie załadowany jako moduł. Sam brak modułu w /proc/modules nie jest pełnym dowodem bezpieczeństwa, ale jest użyteczną informacją operacyjną.

uname -r
cat /etc/os-release

grep -qE '^algif_aead ' /proc/modules \
  && echo 'algif_aead: moduł załadowany' \
  || echo 'algif_aead: moduł nie jest załadowany'

modinfo algif_aead 2>/dev/null | sed -n '1,12p'

Dla Kubernetes warto zebrać wersje kernela bezpośrednio z obiektów Node. To szybciej pokaże, które pule węzłów wymagają rotacji lub aktualizacji obrazu bazowego:

kubectl get nodes -o custom-columns=NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage,RUNTIME:.status.nodeInfo.containerRuntimeVersion

kubectl get nodes -l node-role.kubernetes.io/worker -o wide

W praktyce najczęściej trzeba połączyć dwa działania: aktualizację pakietów kernela lub obrazu node image oraz tymczasową mitygację blokującą podatny moduł tam, gdzie vendor ją zaleca. Nie należy ślepo kopiować obejść między dystrybucjami bez sprawdzenia poradnika producenta, bo dystrybucje różnią się konfiguracją kernela, backportami i pakietami odpowiedzialnymi za ładowanie modułów.

Mitygacja: blokada algif_aead i aktualizacja kernela

Canonical opublikował ręczną mitygację polegającą na utworzeniu wpisu install algif_aead /bin/false w katalogu /etc/modprobe.d/. Jest to ta sama klasa działania, którą Canonical opisał dla aktualizacji pakietu kmod. Jeżeli system nie może od razu dostać poprawionego kernela, blokada modułu jest sensownym krokiem redukującym ryzyko. Trzeba jednak pamiętać, że wyłączenie elementu kryptograficznego może mieć wpływ na aplikacje korzystające ze sprzętowo przyspieszanych funkcji crypto; poprawnie napisane aplikacje powinny przejść na implementacje userspace, ale warto to sprawdzić w testach.

echo 'install algif_aead /bin/false' | sudo tee /etc/modprobe.d/disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null || true

grep -qE '^algif_aead ' /proc/modules \
  && echo 'UWAGA: algif_aead nadal załadowany' \
  || echo 'OK: algif_aead nie jest załadowany'

sudo reboot

Na systemach Debian/Ubuntu należy sprawdzić aktualizacje bezpieczeństwa i obecność mitygacji w pakietach dystrybucji:

sudo apt update
apt list --upgradable 2>/dev/null | grep -E 'linux-image|linux-modules|kmod' || true
sudo apt full-upgrade

Na rodzinie RHEL, Rocky, AlmaLinux, Fedora i Amazon Linux właściwy będzie odpowiedni mechanizm DNF/YUM oraz śledzenie advisory vendora:

sudo dnf check-update --security || true
sudo dnf update --security
sudo reboot

Na SUSE i openSUSE trzeba analogicznie użyć zypper patch lub firmowego kanału aktualizacji:

sudo zypper refresh
sudo zypper list-patches --category security
sudo zypper patch --category security
sudo reboot

Co zrobić w klastrach Kubernetes

Dla Kubernetes najważniejsza jest kolejność. Jeżeli używasz zarządzanego klastra, takiego jak EKS, AKS, GKE albo ich odpowiedniki u innych dostawców, zacznij od sprawdzenia daty i wersji obrazu node image. Sam upgrade control plane nie naprawia kernela na workerach. Trzeba zaktualizować node pool, wymienić AMI lub obraz systemowy, a następnie przeprowadzić rotację węzłów.

Dobry, konserwatywny plan wygląda następująco:

1. Wypisz wszystkie pule węzłów i wersje kernela.
2. Ustal, które węzły obsługują workloady niezaufane, buildy, testy i zadania multi-tenant.
3. Najpierw aktualizuj pule wysokiego ryzyka: CI/CD, sandboxy, platformy deweloperskie i węzły GPU używane przez wielu użytkowników.
4. Przed wymianą węzła wykonaj cordon i drain, z poszanowaniem PodDisruptionBudget.
5. Po rotacji sprawdź, czy nowy kernel i OS image rzeczywiście zawierają poprawkę lub mitygację.

W środowiskach bare metal lub self-managed Kubernetes nie zapomnij o warstwie hosta. Jeżeli aktualizujesz tylko obrazy kontenerów, problem pozostaje. Copy Fail siedzi poniżej runtime’u kontenerowego, w jądrze. Dlatego containerd, CRI-O czy Docker mogą być aktualne, a host nadal podatny.

Monitoring i hunting po ujawnieniu

Po opublikowaniu PoC warto przejrzeć logi, ale trzeba mieć realistyczne oczekiwania. Lokalna eskalacja w jądrze nie zawsze zostawi oczywisty ślad w logach aplikacyjnych. Sensowne punkty obserwacji to nagłe uruchomienia binariów setuid, nietypowe procesy potomne powłok, krótkotrwałe skrypty Pythona, nietypowe użycie AF_ALG oraz anomalie w kontenerach, które wcześniej nie wymagały podwyższonych uprawnień.

W systemach z auditd można rozważyć czasowe reguły obserwujące uruchomienia szczególnie wrażliwych plików. W EDR/XDR warto skorelować informacje o wersji kernela z alertami o lokalnych próbach eskalacji. W klastrach Kubernetes przydatne jest sprawdzenie, które namespace’y mają możliwość uruchamiania obrazów spoza zatwierdzonych registry, z hostPath, privileged, dodatkowymi capabilities lub bez restrykcyjnych profili seccomp/AppArmor.

Praktyczne podsumowanie

Copy Fail to dobry przykład podatności, której nie wolno oceniać wyłącznie przez pryzmat słowa „lokalna”. 29 kwietnia 2026 r. ujawniono błąd w jądrze Linuksa, 1 maja 2026 r. podatność znalazła się w CISA KEV, a administratorzy dostali jasny sygnał: trzeba łatać i mitygować szybko. Priorytetem są hosty uruchamiające cudzy kod: Kubernetes, CI/CD, środowiska deweloperskie, AI/ML i serwery multi-tenant. Sprawdź wersje kernela, zastosuj poprawki dystrybucji, rozważ blokadę algif_aead zgodnie z poradnikiem vendora i nie uznawaj klastra za bezpieczny, dopóki nie wymienisz lub nie zaktualizujesz węzłów worker.

Źródła i dalsza lektura

• NVD – CVE-2026-31431
• CERT-EU Security Advisory 2026-005: High Vulnerability in the Linux Kernel (Copy Fail)
• Canonical: Fixes available for CVE-2026-31431 Copy Fail Linux Kernel Local Privilege Escalation Vulnerability
• Microsoft Security Blog: CVE-2026-31431 Copy Fail vulnerability enables Linux root privilege escalation across cloud environments
• Theori GitHub: copy-fail-CVE-2026-31431