Najpierw konkret: CVE-2026-43284 (xfrm-ESP) ma łatkę w mainline kernela od 8 maja — dystrybuuj ją natychmiast. CVE-2026-43500 (RxRPC) na razie nie ma łatki w większości dystrybucji — tymczasowa mitigacja w sekcji poniżej. Jeśli uruchamiasz Ollama, llama.cpp, LMDeploy, vLLM lub SGLang na Linuksie z dostępem sieciowym — priorytet jest dziś wyższy niż przy typowym kernelowym LPE.
Status łatek:
- Ubuntu: w trakcie
- Red Hat Enterprise Linux / AlmaLinux: kernel 4.18.0-553.123.2.el8_10 w testing
- CloudLinux: patched kernel dostępny 8-9 maja w beta channel
- Debian, Fedora, Arch: w trakcie
- Amazon Linux: w trakcie
Dlaczego embargo się posypało
Hyunwoo Kim (@v4bel) zgłosił oba błędy opiekunom kernela 29-30 kwietnia 2026. 7 maja wysłał szczegóły do prywatnej, zamkniętej listy mailingowej linux-distros@vs.openwall.org — standardowy mechanizm koordynacji ujawnienia, dający dystrybucjom czas na przygotowanie łatek przed pełnym ujawnieniem.
Tego samego dnia embargo zostało złamane przez niezwiązaną osobę trzecią która niezależnie odkryła podatność i opublikowała exploit.
Kim opublikował pełną dokumentację i PoC natychmiast po tym, za wiedzą i zgodą opiekunów dystrybucji. Nie miał wyboru — exploit był już publiczny. Konsekwencja: CVE-2026-43500 (RxRPC) nie ma łatki w żadnej głównej dystrybucji w momencie gdy działający exploit jest dostępny publicznie dla każdego.
To jest dokładnie ta sytuacja którą NIST opisywał jako strukturalny problem zarządzania podatnościami — pisaliśmy o tym przy okazji decyzji o ograniczeniu bazy NVD: między disclosure a eksploitacją nie ma już bufora czasu. Tu bufor zniknął przez złamanie embarga, nie przez szybkość atakujących.
Dwie połówki które pokrywają wzajemne braki
Dirty Frag to łańcuch dwóch osobnych podatności w subsystemach sieciowych kernela Linuksa. SANS ISC handler Yee Ching Tok opisuje architekturę eksploitacji precyzyjnie: "Ani xfrm-ESP Page-Cache Write ani RxRPC Page-Cache Write samodzielnie nie dają wystarczająco niezawodnego prymitywu do pełnej eskalacji do roota. Jednak połączone, eksploit osiąga natychmiastowy root na większości dystrybucji."
CVE-2026-43284 — xfrm-ESP Page-Cache Write. Błąd w podsystemie IPsec (esp4/esp6) który daje atakującemu 4-bajtowy prymityw zapisu do pamięci podręcznej strony. Błąd pochodzi z commita z 2017 roku — i jest ciekawy przez inny szczegół: ten sam commit z 17 stycznia 2017 był też pierwotną przyczyną CVE-2022-27666 który był usuwany cztery lata temu. Zdaniem Kima poprawka tamtego błędu nie usunęła głębszej przyczyny. Dziewięć lat w kodzie produkcyjnym.
Ograniczenie: wymaga uprawnienia do tworzenia przestrzeni nazw użytkownika. Na Ubuntu z AppArmor to uprawnienie jest blokowane dla nieuprzywilejowanych użytkowników — co sprawia że samo CVE-2026-43284 nie jest wystarczające na domyślnych konfiguracjach Ubuntu.
CVE-2026-43500 — RxRPC Page-Cache Write. Błąd w module RxRPC implementującym protokół używany przez rozproszony system plików AFS. Nie wymaga uprawnień do tworzenia przestrzeni nazw — co pokrywa ślepą plamkę ESP. Ograniczenie: moduł rxrpc.ko nie jest domyślnie załadowany w większości dystrybucji.
Razem: xfrm-ESP daje prymityw zapisu, RxRPC daje dostęp bez uprawnień namespace, obydwa modyfikują pamięć podręczną strony kernela w sposób pozwalający na nadpisanie chronionych plików systemowych i eskalację uprawnień. Deterministyczny, bez wyścigu, wysoki wskaźnik sukcesu. Kernel nie crashuje przy nieudanej próbie.
Wiz ujmuje to jednym zdaniem: "Unlike race-condition-based exploits, this bug class is deterministic and highly reliable."
Microsoft: aktywna eksploitacja w atakach
Zanim Copy Fail (CVE-2026-31431) dostał łatkę, PoC opublikowano 29 kwietnia. CISA dodała go do katalogu KEV 1 maja. Dirty Frag jest zgłoszony tydzień po Copy Fail z identyczną klasą błędu i działającym eksploitem dostępnym od razu.
Microsoft Security Blog opublikował 8 maja potwierdzenie aktywnej eksploitacji Dirty Frag w atakach. Sekwencja: zewnętrzne połączenie SSH → interaktywna powłoka → staging i wykonanie pliku ELF ./update → natychmiastowa eskalacja przez su → modyfikacja pliku konfiguracyjnego LDAP systemu GLPI → rekonesans → dostęp do danych sesji.
GLPI to popularny system zarządzania zasobami IT i helpdesk używany przez szpitale, szkoły i instytucje rządowe. Sekwencja opisana przez Microsoft — wejście przez SSH, eskalacja do roota, modyfikacja uwierzytelnienia LDAP, dostęp do sesji użytkowników — to gotowy wzorzec dla ataku na zarządzanie tożsamością całej organizacji.
Microsoft zaznacza że obserwuje "ograniczoną aktywność in-the-wild" związaną z użyciem polecenia su po eskalacji uprawnień — co może wskazywać na Dirty Frag lub Copy Fail. Kilkanaście godzin po publikacji PoC.
Połączenie z infrastrukturą AI
Tu jest warstwa której żadne anglojęzyczne omówienie nie opisało wprost.
W maju cyberflux opisywał serię ataków na frameworki AI działające na Linuksie: Marimo, SGLang, LMDeploy, LiteLLM, llama.cpp i Bleeding Llama.
Wspólna cecha wszystkich tych podatności: atakujący uzyskuje wykonanie kodu jako nieuprzywilejowany użytkownik w środowisku frameworka AI. Brak uwierzytelnienia w Ollama API daje powłokę. SSRF w LMDeploy daje dostęp do metadanych AWS przez nieuprzywilejowany proces. RCE w llama.cpp przez złośliwy plik GGUF daje kod jako użytkownik serwisu.
Dirty Frag jest następnym krokiem w tym łańcuchu: nieuprzywilejowany dostęp → eskalacja do roota przez Dirty Frag. Jeśli atakujący wchodzi przez Ollama API bez uwierzytelnienia i ma lokalny dostęp do systemu — Dirty Frag z działającym PoC dostępnym publicznie to gotowy drugi krok.
Wiz opisuje środowiska szczególnie narażone: maszyny wirtualne i mniej restrykcyjne środowiska (w odróżnieniu od zahardowanego Kubernetes z domyślnymi profilami seccomp). Typowy serwer wnioskowania AI — instancja GPU w chmurze z uruchomionym Ollama lub llama.cpp — to właśnie mniej restrykcyjne środowisko.
Dirty Pipe → Copy Fail → Dirty Frag: klasa błędów która nie znika
Warto umieścić Dirty Frag w kontekście historycznym który Kim sam wskazuje.
Dirty Pipe (CVE-2022-0847, 2022): lokalny zapis do dowolnego pliku przez mechanizm pipe w kernelu. Wysoki profil, szeroka eksploitacja, szybka mitigacja.
Copy Fail (CVE-2026-31431, kwiecień 2026): podobna klasa, inny subsystem. osflux.pl opisał szczegóły techniczne i rekomendacje dla użytkowników Linuksa. CISA dodała do KEV 1 maja.
Dirty Frag (CVE-2026-43284 + CVE-2026-43500, maj 2026): rozszerzenie tej samej klasy błędów na ESP i RxRPC. Kim opisuje to wprost: "Dirty Frag jest przypadkiem który rozszerza klasę błędów do której należą Dirty Pipe i Copy Fail."
Każda z tych podatności wychodzi z tego samego fundamentalnego problemu w zarządzaniu pamięcią podręczną strony kernela: możliwości zapisu do pamięci nie będącej w wyłącznym posiadaniu kernela przez nieuprzywilejowane procesy. Naprawianie konkretnych instancji bez poszukiwania podobnych wzorców w innych subsystemach daje serię podatności zamiast jednej poprawki.
Kim znalazł Dirty Frag szukając dokładnie takich wzorców po Copy Fail. Następna osoba która będzie szukała podobnych wzorców prawdopodobnie też coś znajdzie.
Tymczasowa mitigacja zanim pojawią się łatki
Dla CVE-2026-43500 (RxRPC) który nadal nie ma łatki dystrybucyjnej:
bash
# Zablokowanie modułów xfrm i rxrpc (eliminuje oba wektory)
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
# UWAGA: wyłączenie esp4/esp6 może przerwać działanie IPsec/VPN
# Wyłączenie rxrpc może przerwać AFS — na większości serwerów nie jest używany
Red Hat dodaje: na RHEL 9 i 10 wyłączenie ESP blokuje wariant xfrm, ale wariant rxrpc pozostaje eksploitowalny — oba moduły muszą być zablokowane żeby mitigacja była kompletna.
Alternatywnie, wyłączenie nieuprzywilejowanych przestrzeni nazw użytkownika blokuje wariant ESP na systemach które go wymagają:
bash
echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf
sysctl --system
Uwaga: to może wpłynąć na kontenery rootless, Flatpak i piaskownicowane przeglądarki.
Po wdrożeniu łatek kernelowych — cofnij mitigacje, zrestartuj.
Podsumowanie
Dirty Frag to trzecia duża podatność klasy Dirty Pipe w ciągu czterech lat — ta sama klasa błędów, inny subsystem, ten sam efekt. Działający exploit dostępny publicznie przed łatkami dla większości dystrybucji, aktywna eksploitacja potwierdzona przez Microsoft, eskalacja z nieuprzywilejowanego użytkownika do roota bez wyścigu i bez crashowania kernela.
Dla infrastruktury AI na Linuksie — serwery wnioskowania, węzły GPU w chmurze, maszyny z Ollama i llama.cpp — Dirty Frag jest naturalnym drugim krokiem po każdej podatności dającej nieuprzywilejowany dostęp przez framework AI. Tych podatności było w maju pięć.
Aktualizacja kernela. Teraz.
Źródła
BleepingComputer — pierwotne doniesienie z detalami złamanego embarga i statusem łatek: https://www.bleepingcomputer.com/news/security/new-linux-dirty-frag-zero-day-with-poc-exploit-gives-root-privileges/
Microsoft Security Blog — potwierdzenie aktywnej eksploitacji i sekwencja ataku GLPI: https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/
Tenable — FAQ techniczne z CVE i kontekstem Copy Fail: https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe
Wiz Research — analiza z perspektywy bezpieczeństwa chmurowego i środowisk kontenerowych: https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc
Red Hat RHSB-2026-003 — oficjalne advisory z instrukcjami mitigacji: https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
Help Net Security — szczegóły złamanego embarga i komentarz SANS ISC: https://www.helpnetsecurity.com/2026/05/08/dirty-frag-linux-vulnerability-cve-2026-43284-cve-2026-43500/
osflux.pl — szczegóły techniczne i rekomendacje dla Copy Fail (poprzednia podatność tej klasy): https://osflux.pl/linux/copy-fail-luka-w-jadrze-linuksa-daje-roota-w-10-liniach-kodu-ubuntu-debian-fedora-red-hat-jesli-uzywasz-linuksa-zaktualizuj-jadro-teraz/















































































































Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł