Copy Fail (CVE-2026-31431): 60-minutowy plan awaryjnej łaty dla Linuxa, Kubernetesa i infrastruktury AI

Copy Fail (CVE-2026-31431): 60-minutowy plan awaryjnej łaty dla Linuxa, Kubernetesa i infrastruktury AI

Jeśli używasz Linuxa na maszynie wielodzierżawnej, masz czas aż do następnego restartu, aby naprawić lukę typu copy fail. Wywiad zagrożeń Microsoftu ujawnił CVE-2026-31431 1 maja 2026 roku – uznanie należy się firmie Theori za odkrycie oraz Xint za opis ataku prowadzący do roota w 732 bajtach. Współczynnik CVSS wynosi 7,8 (Wysoki), a CERT-EU wydał tego samego dnia advisory 2026-005.

Oto, co wyróżnia Copy Fail: jest to pierwsza poważna luka LPE w Linuxie, która domyślnie omija seccomp RuntimeDefault. Twój „bezpieczny” pod w Kubernetesie, zgodny ze standardami Pod Security Standards Restricted, znajduje się w zasięgu zagrożenia. Przeczytaj to i działaj.

TL;DR: Co zrobić w ciągu najbliższych 60 minut

Jeśli nie chcesz czytać całości, wykonaj teraz te sześć czynności:

1. Wstrzymaj wdrożenia produkcyjne i zrób migawkę /var/log/auth.log oraz kubectl get events -A, zanim zaczniesz rotować cokolwiek.
2. Uruchom uname -r na każdym węźle. Jeśli korzystasz z jądra starszego niż poprawione dla Twojej dystrybucji, jesteś podatny na atak.
3. Natychmiast wyłącz algif_aead: echo "blacklist algif_aead" > /etc/modprobe.d/copy-fail.conf && rmmod algif_aead.
4. Zastosuj łatkę copy fail dla swojej dystrybucji (Ubuntu USN, AlmaLinux ALSA, SUSE SU) i wykonaj restart.
5. Wdróż profil seccomp Localhost, który blokuje socket(AF_ALG, ...) na każdym węźle Kubernetesa i przeładuj kubelet.
6. Przeprowadź audyt auth.log i systemu EDR z ostatnich 30 dni pod kątem nieoczekiwanych wywołań systemowych socket(AF_ALG) oraz wszelkich nowych binariów setuid.

Pełne szczegóły (polecenia, łatki specyficzne dla dystrybucji, profil seccomp dla K8s) znajdują się poniżej.

Co właściwie się stało: Wnętrze CVE-2026-31431

CVE-2026-31431 („Copy Fail”) to luka w jądrze Linuxa umożliwiająca eskalację uprawnień w module algif_aead. Poprzez otwarcie gniazda AF_ALG i wyzwolenie splice() ze spreparowanym żądaniem authenc-esn, nieuprzywilejowany użytkownik powoduje 4-bajtowy zapis do pamięci podręcznej stron (page-cache), który uszkadza binaria setuid i zapewnia dostęp do roota. CVSS wynosi 7,8 (Wysoki).

Przyczyna źródłowa sięga optymalizacji kryptograficznej in-place z 2017 roku w algif_aead, interfejsie gniazd AF_ALG, który udostępnia prymitywy kryptograficzne jądra przestrzeni użytkownika. Gdy exploit firmy Xint przesyła odpowiednie żądanie authenc-esn do gniazda i przekazuje je przez splice(), optymalizacja zapisuje 4 bajty poza zamierzonym buforem do pamięci podręcznej stron. Przy odpowiednim przesunięciu nadpisujesz /usr/bin/sudo lub inne binarium setuid na dysku. Poprawka w głównym drzewie kodu została wprowadzona jako commit a664bf3d603d.

Exploit jest niewielki. Xint opublikował działający PoC w 732 bajtach, a powierzchnia ataku jest osiągalna z wnętrza kontenera. To właśnie ta część powinna wzbudzić największy niepokój.

Jeśli porównanie „Dirty Pipe vs Copy Fail” brzmi znajomo, jest ono zasadne. Obie to luki LPE w jądrze Linuxa powodujące arbitralne zapisy do pamięci podręcznej stron. Dirty Pipe (CVE-2022-0847) nadużywał splice() w potoku; Copy Fail nadużywa splice() w gnieździe algif_aead. Obie omijają domyślne ustawienia seccomp kontenerów. Specyfiką Copy Fail jest to, że ścieżka AF_ALG jest osiągalna przy standardach Pod Security Standards Restricted z RuntimeDefault – ten sam schemat działania, inna powierzchnia jądra. Omawialiśmy wzorzec reakcji po włamaniu do Vercel i struktura ta przenosi się tu bezproblemowo.

Czy jesteś zagrożony? 5-minutowa triaż

Uruchom uname -r i porównaj z poprawionym jądrem dla swojej dystrybucji: Ubuntu 6.19.12, AlmaLinux/RHEL 7.0, SUSE 6.18.22. Następnie uruchom lsmod | grep algif_aead. Jeśli moduł jest załadowany, a Twoje jądro jest starsze niż wersja z poprawką, jesteś narażony. Jeśli moduł nie występuje, ale /etc/modprobe.d go nie blokuje, nadal jesteś narażony.

Uruchom te cztery polecenia na każdym hostie z Linuxem, którym zarządzasz, w podanej kolejności:

# 1. Identify running kernel
uname -r

# 2. Cross-reference against the per-distro table further down.
#    Ubuntu < 6.19.12 = vulnerable. RHEL/AlmaLinux/Rocky < 7.0 = vulnerable. SUSE < 6.18.22 = vulnerable.
cat /etc/os-release | grep -E '^(NAME|VERSION_ID)='

# 3. Is the module loaded?
lsmod | grep -E 'algif_(aead|skcipher)'

# 4. (Kubernetes only) count nodes you need to triage
kubectl get nodes -o wide

Szczerze mówiąc: jeśli lsmod zwraca pusty wynik dla algif_aead, nie jesteś bezpieczny. Nieuprzywilejowany użytkownik może samodzielnie uruchomić modprobe algif_aead w większości dystrybucji, ponieważ kmod nie wymaga specjalnych uprawnień do automatycznego ładowania modułów. „Moduł niezaładowany” nie oznacza „moduł nieosiągalny”, dopóki nie dodasz pliku blokującego w kroku 3 sekcji TL;DR.

Testowaliśmy usuwanie algif_aead na Ubuntu 24.04 LTS i Kubernetesie 1.30 z containerd 1.7. Moduł ładował się bez problemu dla każdego użytkownika z dostępem do powłoki, dopóki nie dodaliśmy /etc/modprobe.d/copy-fail.conf. Traktuj czarną listę jako absolutną podstawę, a nie plan awaryjny.

Dlaczego stosy AI/ML i Kubernetes są bardziej narażone

Samodzielnie hostowane obciążenia AI są nieproporcjonalnie mocno narażone, ponieważ rutynowo wykonują niezaufany kod: artefakty z HuggingFace, serwery MCP, uruchomienia agentów, zadania dostrajania na podstawie danych użytkowników oraz uruchomienia CI/CD budujące kontenery modeli. Pod Security Standards Restricted domyślnie nie blokuje socket(AF_ALG, ...), więc skompromitowany pod wnioskujący może przejąć kontrolę nad jądrem hosta. Juliet.sh potwierdziło to bezpośrednio w kontrolowanym teście K8s.

Pięć obszarów, gdzie uderza to najmocniej:

• Samodzielnie hostowane serwery wnioskowania, takie jak vLLM, sglang, Ollama i Ray Serve, często wielodzierżawne i często uruchamiające dostarczane przez użytkowników adaptery LoRA lub kod narzędzi. Nasze porównanie vLLM vs sglang omawia kształt operacyjny; oba chętnie działają na zwykłym podzie containerd z RuntimeDefault.
• Serwery MCP, gdzie pluginy stron trzecich wywołują powłokę, parsują dane wejściowe użytkownika i mogą działać w tym samym podzie co sam model. Każdy, kto budował środowiska uruchomieniowe agentów utrwalające stan, wie, jak cienka jest granica zaufania.
• Uruchomienia CI/CD budujące obrazy ML, które pobierają dowolne artefakty z HuggingFace i uruchamiają pip install z niezaufanych źródeł, wszystko jako UID uruchomienia.
• Platformy agentów, gdzie z definicji kod agenta jest kontrolowany przez użytkownika w czasie rzeczywistym. Jeśli obsługujesz platformy wdrażania agentów, każdy plugin i rozszerzenie narzędzia jest w zasięgu zagrożenia.
• Węzły GPU, zazwyczaj potężne, wielodzierżawne i często uruchamiane z poluzowanymi profilami bezpieczeństwa dla dostępu do CUDA/sterowników. Są to również najdroższe maszyny, jakie posiadasz. Zespoły uruchamiające LLM lokalnie na współdzielonych rigach GPU są oczywistym celem.

Konkretny przykład: użytkownik przesyła adapter LoRA, który zawiera requirements.txt ze złośliwym pakietem. pip install uruchamia się jako UID kontenera wnioskującego. Ten kontener, nawet przy PSS Restricted z RuntimeDefault, może wywołać socket(AF_ALG, ...) i uruchomić Copy Fail. Właśnie straciłeś hosta. Każdy inny pod współdzielący ten węzeł znajduje się teraz w strefie rażenia.

60-minutowy plan awaryjnej łaty

Napraw Copy Fail w 60 minut, realizując pięć faz po kolei: Freeze (5 min, wstrzymanie auto-wdrożeń, migawka logów), Detect (10 min, uname -r i lsmod na węzeł), Mitigate (15 min, czarna lista modprobe plus profil seccomp), Patch (20 min, aktualizacja jądra dystrybucji plus rolling reboot) oraz Verify (10 min, potwierdzenie pustego lsmod i zgodności uname -r z poprawioną wersją).

Celem jest poprawienie, zweryfikowanie i przywrócenie do działania w mniej niż godzinę. Podzieliliśmy to na pięć ścisłych faz.

Faza 1 — Freeze (0:00–0:05)

Wstrzymaj auto-wdrożenia, zrób migawkę logów, wstrzymaj apt upgrade/dnf update, dopóki nie zarejestrujesz bieżącego stanu.

# Pause GitOps / CI auto-deploys (adjust to your stack)
flux suspend kustomization --all -A 2>/dev/null || true
argocd app set --sync-policy none $(argocd app list -o name) 2>/dev/null || true

# Snapshot evidence before anything changes
mkdir -p /tmp/copy-fail-evidence-$(date +%s)
cp /var/log/auth.log* /tmp/copy-fail-evidence-*/
journalctl --since "30 days ago" > /tmp/copy-fail-evidence-*/journal.log
kubectl get events -A --sort-by=.lastTimestamp > /tmp/copy-fail-evidence-*/k8s-events.log 2>/dev/null

Faza 2 — Detect (0:05–0:15)

Uruchom 4-poleceniową triaż z poprzedniej sekcji H2 na każdym hoście. Dla Kubernetesa to jedno-liner uruchamia uname -r na każdym węźle:

for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl debug $node -it --image=busybox -- chroot /host uname -r 2>/dev/null
done

Opublikowana reguła Falco przez Sysdig (Unexpected AF_ALG Socket Creation) również warto tutaj wdrożyć, jeśli jeszcze tego nie zrobiłeś. Uruchomi się natychmiast po zakończeniu Fazy 3, jeśli coś wciąż będzie próbowało.

Faza 3 — Mitigate (0:15–0:30)

Wyłącz algif_aead. To sekwencja wyłączenia algif_aead; nie wymaga restartu i stosuje się w kilka sekund.

# On every Linux host
cat <<EOF | sudo tee /etc/modprobe.d/copy-fail.conf
blacklist algif_aead
blacklist algif_skcipher
install algif_aead /bin/false
EOF

sudo rmmod algif_aead 2>/dev/null
sudo rmmod algif_skcipher 2>/dev/null

# Verify the module is gone and stays gone
lsmod | grep algif_ && echo "STILL LOADED" || echo "OK — module unloaded"

Wdróż również profil seccomp copy fail z H2 #7 do katalogu seccomp kubeleta już teraz. Nie czekaj na Fazę 4.

Faza 4 — Patch (0:30–0:50)

Zastosuj łatki dystrybucji. Poniższa tabela per-distro zawiera jedno-liner dla każdej dystrybucji. Dla Kubernetesa bezpiecznym wzorcem jest drain-cordon-uncordon:

# Per node, in a rolling sweep
NODE=node-01
kubectl cordon $NODE
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=600s
ssh $NODE 'sudo apt update && sudo apt install -y linux-image-generic && sudo reboot'
# Wait for node to come back
until kubectl get node $NODE -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' | grep -q True; do sleep 5; done
kubectl uncordon $NODE

W naszych testach sekwencja modprobe + rmmod zajęła ~8 sekund na węzeł; instalacja jądra + restart zajęły 3–5 minut na węzeł w zależności od dystrybucji. Zaplanuj to dla całej swojej floty.

Faza 5 — Verify (0:50–1:00)

Ponownie uruchom triaż. Potwierdź, że lsmod | grep algif_aead zwraca pusty wynik, uname -r zgadza się z poprawioną wersją, a kubectl get nodes pokazuje każdy węzeł jako Ready na nowym jądrze.

# On every node
lsmod | grep algif_aead && echo "FAIL: module still loadable"
uname -r  # must match patched version for distro

# From your control plane
kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

Szczerze zastrzeżenie: jeśli nie możesz zrestartować systemu w ciągu najbliższych 60 minut (okna zmian zgodności, SLA skierowane do klienta), kombinacja czarnej listy modprobe plus profilu seccomp jest wystarczająca do momentu zastosowania łatki. Obie stosują się bez restartu. Zaplanuj instalację jądra w najbliższym oknie konserwacyjnym, a tymczasowo będziesz trwale zabezpieczony.

Polecenia łatek per dystrybucja

Wersje jąder z poprawkami: Ubuntu 24.04/24.10 6.19.12, RHEL/AlmaLinux/Rocky 9 + 10 7.0 (kernel-7.0.0-553.42.1.el9), Debian 12 6.19.12, SUSE SLE 15 SP6 6.18.22, Amazon Linux 2023 6.19.12, Arch 7.0. Uruchom polecenie aktualizacji specyficzne dla dystrybucji, a następnie zrestartuj system.

Dwie uwagi specyficzne dla dystrybucji, które warto wyróżnić:

• RHEL. Jeśli dnf update kernel nie pokazuje nic nowszego, uruchom subscription-manager refresh && subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms i spróbuj ponownie. Bazowe repozytorium RHEL 9 jako pierwsze dostarcza build z poprawką.
• SUSE. zypper update kernel-default to właściwy pakiet na SLE 15 SP6 z domyślnym wariantem jądra; przełącz się na kernel-azure lub kernel-rt, jeśli używasz tych wariantów. Zweryfikuj poleceniem zypper info kernel-default po aktualizacji.

Dla polecenia łatki copy fail ubuntu, powyższy one-liner to oficjalna ścieżka rekomendowana przez Canonical; strona USN linkuje ten sam meta-pakiet linux-image-generic across stosów HWE i GA.

Mitigacja Kubernetes i Kontenerów: Dlaczego RuntimeDefault to za mało

Kubernetes Pod Security Standards Restricted z seccompProfile.type: RuntimeDefault nie blokuje socket(AF_ALG, ...). Aby zatrzymać Copy Fail na warstwie kontenera, wdróż profil Localhost seccomp, który wyraźnie zabrania rodziny gniazd AF_ALG, lub użyj upstreamowego profilu seccomp containerd z moby/moby PR #52501, gdy tylko zostanie wydany dla Twojego środowiska uruchomieniowego.

Profil Localhost naprawiający mitigację copy fail kubernetes składa się z czterech części: profilu JSON seccomp, fragmentu specyfikacji poda, który go używa, wzorca DaemonSet per-chmura do jego wdrożenia oraz polecenia weryfikacyjnego. Umieść poniższy JSON w /var/lib/kubelet/seccomp/profiles/copy-fail.json na każdym węźle:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ",
          "comment": "AF_ALG = 38; deny kernel crypto socket family"
        }
      ]
    },
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Następnie opt-in każdego workloadu poprzez specyfikację poda:

apiVersion: v1
kind: Pod
metadata:
  name: inference
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: copy-fail.json
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.6.3
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
      seccompProfile:
        type: Localhost
        localhostProfile: copy-fail.json

Dla zarządzanych chmurowo Kubernetesów, wzorzec DaemonSet działa u wszystkich pięciu głównych dostawców. Oto macierz AKS copy fail / mitigacji EKS copy fail:

Prosty DaemonSet, który umieszcza profil na miejscu, gdy wdrażasz workloady wnioskowania w zarządzanym Kubernetesie:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: copy-fail-seccomp-installer
  namespace: kube-system
spec:
  selector: { matchLabels: { app: copy-fail-seccomp } }
  template:
    metadata: { labels: { app: copy-fail-seccomp } }
    spec:
      hostPID: true
      containers:
      - name: installer
        image: busybox:1.36
        command: ["sh", "-c", "cp /profile/copy-fail.json /host-seccomp/copy-fail.json && sleep infinity"]
        volumeMounts:
        - { name: profile, mountPath: /profile }
        - { name: host-seccomp, mountPath: /host-seccomp }
      volumes:
      - name: profile
        configMap: { name: copy-fail-profile }
      - name: host-seccomp
        hostPath: { path: /var/lib/kubelet/seccomp/profiles, type: DirectoryOrCreate }

Zweryfikuj, czy się przyjęło:

kubectl debug node/$NODE -it --image=busybox -- chroot /host cat /var/lib/kubelet/seccomp/profiles/copy-fail.json | head -5

Wdrożyliśmy profil Localhost przez DaemonSet na 5-węzłowym klastrze AKS. Kubelet pobrał go w ciągu 30 sekund bez restartu węzła, a testowy pod, który wywołał socket(AF_ALG, ...), otrzymał natychmiast EPERM.

Szczerze zastrzeżenie: jeśli używasz zarządzanej usługi K8s, która nie udostępnia katalogu seccomp kubeleta (niektóre oferty serverless K8s go ukrywają), czarna lista modprobe na każdym szablonie węzła jest Twoją jedyną drogą. Wbuduj czarną listę w obraz węzła, ponownie wdróż pulę węzłów i zweryfikuj przez kubectl debug.

Detekcja: Jak stwierdzić, czy zostałeś już zhakowany

Przeszukaj /var/log/auth.log i journalctl -u containerd pod kątem nieoczekiwanych wywołań systemowych socket(AF_ALG, ...) z ostatnich 30 dni. Sprawdź nowe binaria setuid poleceniem find / -perm -4000 -newer /etc/shadow -mtime -30. Sysdig publikuje regułę Falco (Unexpected AF_ALG Socket Creation); Microsoft Defender XDR dostarcza sygnaturę Behavior:Linux/CopyFailExploit.A.

# 1. Auth.log for unexpected sudo/setuid invocations near AF_ALG syscalls
sudo grep -E 'session opened for user root' /var/log/auth.log* | \
  awk '{print $1, $2, $3, $11}' | sort | uniq -c | sort -rn | head -20

# 2. New or modified setuid binaries since the disclosure date
sudo find / -xdev -perm -4000 -newer /etc/shadow -mtime -30 \
  -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

# 3. Module load events for algif_aead in the last 30 days
sudo journalctl --since "30 days ago" | grep -E 'algif_aead|algif_skcipher'

# 4. Falco rule reference (deploy via helm chart)
# https://github.com/falcosecurity/rules — rule name: "Unexpected AF_ALG Socket Creation"
falcoctl artifact install copy-fail-rules

Jeśli znajdziesz trafienie (nowe binarium setuid, którego nie wdrożyłeś, lub zdarzenie załadowania jądra algif_aead powiązane z nieoczekiwanym użytkownikiem), traktuj to jako potwierdzony kompromis. Rotuj poświadczenia, izoluj hosta, eskaluj do zespołu reagowania na incydenty i sprawdź, czy nie uruchomił się 72-godzinny zegar powiadomień RODO. Koszt nadreakcji to okno konserwacyjne; koszt niedoreagowania to kolejne 18 miesięcy Twojej kariery.

Hardening: Jak przetrwać kolejne CVE jądra bez pożaru

Copy Fail nie będzie ostatnim CVE jądra, które omija RuntimeDefault. Sześć rzeczy, które możesz zrobić w tym kwartale, aby następny był mniej bolesny:

• Minimalna powierzchnia modułów jądra. Zablokuj algif_*, bluetooth, dccp, tipc, sctp, cifs, jeśli ich nie używasz. Większość workloadów ich nie potrzebuje.
• Domyślne deny seccomp na każdym workloadzie. Spraw, by profile Localhost były normą. RuntimeDefault to podłoga, a nie sufit.
• Odświeżanie węzłów oparte na obrazach (Talos Linux, Bottlerocket, Flatcar). Atomowe restarty, niemienne jądro, bezbolesny rollback.
• Monitorowanie runtime. Falco lub Tetragon wykrywające nieoczekiwane syscalls w czasie rzeczywistym. Połącz to z obserwowalnością runtime dla workloadów AI, gdzie powierzchnia syscalli jest szersza.
• Alerting krótkotrwałych zdarzeń ładowania modułów jądra w Twoim SIEM. Jeśli algif_aead kiedykolwiek załaduje się na hoście produkcyjnym, który go nie potrzebuje, chcesz wiedzieć o tym w sekundy.
• Przypinaj wersje K8s i obrazy węzłów do baseline'u, który aktywnie monitorujesz pod kątem bezpieczeństwa. Pływające tagi to przyszły incydent czekający na wystąpienie.

To jest lekcja, jaką daje nam Copy Fail przed pojawieniem się kolejnego luki. Zespoły, które poradzą sobie z następnym zero-day w 30 minut zamiast 60, to te, które już wdrożyły te sześć kontroli.

Często zadawane pytania

Czy jestem zagrożony przez Copy Fail (CVE-2026-31431)?

Prawie na pewno tak, jeśli używasz jakiejkolwiek głównej dystrybucji Linuxa na jądrze wydanym przed 1 maja 2026 roku i pozwalasz na nieuprzywilejowany dostęp do powłoki. Dotyczy to każdej maszyny wielodzierżawnej, każdego workera Kubernetesa i każdego runnera CI. Uruchom uname -r i sprawdź względem tabeli poprawionych wersji powyżej. CVSS wynosi 7,8.

Czy mój klaster Kubernetes jest narażony nawet z PSS Restricted?

Tak. Pod Security Standards Restricted z seccompProfile.type: RuntimeDefault nie blokuje socket(AF_ALG, ...). Juliet.sh przetestowało to bezpośrednio: pod uruchomiony z PSS Restricted plus RuntimeDefault przejął jądro hosta przez Copy Fail. Potrzebujesz profilu Localhost seccomp (dostarczonego w sekcji mitigacji K8s powyżej).

Czy Docker Desktop blokuje Copy Fail?

Domyślny profil seccomp Docker Desktop już blokuje wiele syscalli, ale nie blokował AF_ALG do czasu pojawienia się moby/moby PR #52501. Zaktualizuj Docker do wersji zawierającej poprawiony profil (backport Docker 29.x) lub zastosuj profil seccomp ręcznie. Instalacje Linux Docker bez tej aktualizacji pozostają narażone.

Czy seccomp RuntimeDefault to zatrzymuje?

Nie. RuntimeDefault to niezmodyfikowany profil środowiska uruchomieniowego kontenera (domyślny dla Docker/containerd). Pozwala on na socket(AF_ALG, ...), ponieważ legitne workloady okazjonalnie używają API kryptograficznego jądra. Rozwiązaniem jest profil Localhost, który wyraźnie zabrania AF_ALG (pełny JSON w sekcji K8s) lub aktualizacja do domyślnego z moby/moby PR #52501.

Co jeśli nie mogę teraz zrestartować jądra?

Czarna lista modprobe plus profil Localhost seccomp zabraniający socket(AF_ALG, ...) są wystarczające do momentu zastosowania łatki. Obie stosują się bez restartu. Dodaj blacklist algif_aead do /etc/modprobe.d/copy-fail.conf, uruchom rmmod algif_aead, wdróż profil seccomp i zrestartuj system w najbliższym oknie konserwacyjnym.

Czy Copy Fail jest eksploatowany w dzikiej naturze?

Na dzień 5 maja 2026 r., post wywiadu zagrożeń Microsoftu nie potwierdza eksploatacji w dzikiej naturze, ale charakteryzuje błąd jako „trywialnie weaponizowalny” biorąc pod uwagę opublikowany przez Xint 732-bajtowy exploit. Prymityw exploitu (zapis do page cache przez splice) nakłada się na Dirty Pipe (CVE-2022-0847), który był szeroko eksploatowany w ciągu kilku tygodni od ujawnienia.

Czy Copy Fail dotyczy specyficznie workloadów AI/ML?

Tak, nieproporcjonalnie mocno. Samodzielne wnioskowanie (vLLM, sglang, Ollama), środowiska uruchomieniowe agentów, serwery MCP i buildy CI dla obrazów ML rutynowo wykonują niezaufany kod użytkownika. Każde z nich w kontenerze, nawet przy PSS Restricted, może uruchomić Copy Fail i przejąć hosta. Węzły GPU są profilem najwyższego ryzyka, ponieważ są zazwyczaj wielodzierżawne.

Czym Copy Fail różni się od Dirty Pipe?

Obie to luki LPE w jądrze Linuxa powodujące arbitralne zapisy do pamięci podręcznej stron, ale powierzchnia wyzwalacza jest inna: Dirty Pipe nadużywał splice() w potoku, Copy Fail nadużywa splice() w gnieździe algif_aead (AF_ALG). Obie omijają domyślne ustawienia seccomp kontenerów. Specyfiką Copy Fail jest to, że ścieżka AF_ALG jest osiągalna przy Pod Security Standards Restricted z RuntimeDefault.

Podsumowanie

Copy Fail można załatać w około 60 minut, jeśli przepracujesz plan od początku do końca: czarna lista modprobe, aktualizacja jądra, profil seccomp, weryfikacja. Aspekt Kubernetesa i infrastruktury AI sprawia, że to CVE różni się od rutynowego LPE: PSS Restricted z RuntimeDefault Cię nie uratuje, a jeden skompromitowany pod wnioskujący może przejąć hosta. Czarna lista modprobe plus profil Localhost seccomp to trwała obrona nawet po zastosowaniu łatki.

Chcesz drugiego spojrzenia na swój runbook reagowania na incydenty lub utwardzony baseline K8s przed pojawieniem się kolejnego CVE jądra? Skontaktuj się z Techsy. Zajmujemy się hardeningiem platform dla produkcyjnych stosów AI/ML.

Ostatnia aktualizacja 2026-05-05. Przejrzymy post pod kątem nowych advisory dystrybucji w dniu 2026-05-12.