Dystrybucje dotknięte przez DirtyDecrypt: Fedora, Arch Linux, openSUSE Tumbleweed — te które kompilują kernel z CONFIG_RXGK=y. Ubuntu, Debian, Red Hat Enterprise Linux, Amazon Linux — nie dotknięte domyślnie, bo nie włączają tego modułu.
Weryfikacja: grep CONFIG_RXGK /boot/config-$(uname -r). Jeśli wynik to CONFIG_RXGK=y lub CONFIG_RXGK=m — jesteś dotknięty. Łatka jest w mainline od 25 kwietnia, dystrybucje wdrażają ją teraz.
9 maja 2026 roku Luna Tong z Zellic i zespół V12 zgłosili błąd w kernelu Linuksa. Maintainerzy odpowiedzieli szybko: to duplikat, podatność jest już naprawiona w mainline. CVE nie zostało przypisane.
To była poprawna odpowiedź. Łatka rzeczywiście była w mainline od 25 kwietnia.
Problem: nikt nie wiedział że istnieje. Commit nie miał żadnego opisu który by sygnalizował znaczenie security. Dystrybucje nie wiedziały że mają wdrożyć poprawkę. Przez trzy tygodnie łatka na krytyczną podatność siedziała w mainline kernela — naprawiona, dostępna, i kompletnie niewidoczna dla każdego procesu patch management który opiera się na CVE i oficjalnych advisories.
18 maja Zellic i V12 opublikowali PoC. Dopiero wtedy wszyscy dowiedzieli się że od trzech tygodni mają niezaktualizowany system.
Jak działa DirtyDecrypt
CVE-2026-31635, CVSS 7.5. Podatność siedzi w rxgk_decrypt_skb() — funkcji deszyfrującej przychodzące bufory sieciowe w podsystemie RxGK, warstwie bezpieczeństwa GSS-API dla protokołu RxRPC używanego przez klienta systemu plików Andrew (AFS).
Luna Tong opisuje rdzeń problemu jednym zdaniem: "rxgk pagecache write due to missing COW guard in rxgk_decrypt_skb."
Brakujący COW (copy-on-write) guard oznacza że gdy kernel deszyfruje przychodzący socket buffer, zapisuje bezpośrednio do współdzielonej strony pamięci podręcznej zamiast najpierw tworzyć prywatną kopię. Ten niezabezpieczony zapis ląduje w pamięci uprzywilejowanych procesów lub w pamięci podręcznej uprzywilejowanych plików — /etc/shadow, /etc/sudoers, binaria SUID. Efekt: nieuprzywilejowany użytkownik lokalny może nadpisać te pliki i uzyskać root.
Ta sama klasa błędu co Copy Fail, Dirty Frag i Fragnesia — brakujący COW guard w różnych subsystemach sieciowych kernela. Czwarta podatność tej klasy w maju 2026 roku.
W środowiskach konteneryzowanych: węzły robocze z podatnym kernelem mogą być punktem ucieczki z poda — lokalny root na węźle to droga do całego klastra.
"Duplikat" jako problem komunikacyjny
SecurityAffairs opisuje wyjątkowy kontekst tej podatności precyzyjnie: Zellic i V12 odkryli DirtyDecrypt niezależnie, zgłosili, i zostali poinformowani że to duplikat już naprawionego błędu. To jest poprawna odpowiedź z perspektywy kernel maintainerów — patch był w mainline.
Problem leży gdzie indziej: cichy merge bezpieczeństwa bez CVE i bez advisory sprawia że dystrybucje nie wiedzą że mają do wdrożenia łatkę. Łatka na Copy Fail dostała własne CVE i advisory — i dystrybucje wdrożyły ją w ciągu tygodni. Łatka na DirtyDecrypt istniała od 25 kwietnia jako nienazwany commit — i żadna dystrybucja jej nie wdrożyła przez prawie miesiąc.
Cyberpress odnotowuje że NVD włączyło link do DirtyDecrypt PoC do rekordu CVE-2026-31635 dopiero po publikacji PoC przez Zellic — co jest sygnałem że klasyfikacja była retroaktywna, a nie prewencyjna.
Zellic w opisie PoC napisał wprost: "We found and reported this on May 9, 2026, but was informed it was a duplicate by the maintainers. We're releasing it now since it's patched on mainline."
Logika jest poprawna: łatka jest dostępna, ujawnienie nie tworzy nowego okna. Ale konsekwencja jest taka że PoC i świadomość istnienia podatności trafiają do świata jednocześnie — bez okna dla dystrybucji na wdrożenie łatki, które przy cichym merge już nie miało jak zadziałać.
Czwarta w miesiąc, ta sama klasa
Maj 2026 dla kernela Linuksa:
Copy Fail (CVE-2026-31431) — 29 kwietnia, AF_ALG cryptographic socket interface, brakujący COW guard.
Dirty Frag (CVE-2026-43284, CVE-2026-43500) — 7 maja, XFRM ESP i RxRPC, aktywna eksploitacja potwierdzona przez Microsoft.
Fragnesia (CVE-2026-46300) — 13 maja, ESP-in-TCP, efekt uboczny łatki na Dirty Frag. Łatka z kodu Source naprawiła jeden błąd i otworzyła drugi.
DirtyDecrypt (CVE-2026-31635) — 18 maja PoC, RxGK, naprawiony cicho 25 kwietnia, niewidoczny przez prawie miesiąc.
Cztery podatności, jedna klasa: brakujący COW guard w różnych subsystemach sieciowych. Zellic wprost opisuje DirtyDecrypt jako "variant of Copy Fail / Dirty Frag / Fragnesia."
Wzorzec który opisywaliśmy przy Fragnesia jest potwierdzony: gdy jedna podatność tej klasy jest publicznie udokumentowana, badacze szukają tego samego wzorca w sąsiednich subsystemach. Każdy znaleziony błąd jest osobnym odkryciem — ale wszystkie są manifestacjami tego samego problemu architektonicznego.
Co robić
Dystrybucje dotknięte to te z CONFIG_RXGK włączonym — Fedora, Arch Linux, openSUSE Tumbleweed. Dla Fedory aktualizacja kernela przez standardowy dnf update kernel powinna wdrożyć łatkę. Dla Arch: pacman -Syu. Dla openSUSE: zypper update kernel-default.
Jeśli środowisko wymaga CONFIG_RXGK dla AFS client — po wdrożeniu łatki żadna dodatkowa akcja nie jest wymagana. Moduł nadal działa.
Dla środowisk konteneryzowanych na dotkniętych dystrybucjach: weryfikacja wersji kernela węzłów roboczych jest priorytetem — DirtyDecrypt w połączeniu z podatnościami frameworków AI dającymi nieuprzywilejowany dostęp to gotowy dwukrokowy łańcuch eskalacji który opisywaliśmy przy llama.cpp i Bleeding Llama.
Źródła
The Hacker News — pełna analiza z detalami CVE i CONFIG_RXGK: https://thehackernews.com/2026/05/dirtydecrypt-poc-released-for-linux.html
BleepingComputer — oś czasu od cichego merge do PoC: https://www.bleepingcomputer.com/news/security/exploit-available-for-new-dirtydecrypt-linux-root-escalation-flaw/
SecurityAffairs — kontekst "duplikat" i komunikacja między badaczami a maintainerami: https://securityaffairs.com/192436/uncategorized/dirtydecrypt-poc-released-for-yet-another-linux-flaw.html
CyberPress — szczegóły techniczne rxgk_decrypt_skb i brakującego COW guard: https://cyberpress.org/poc-code-dirtydecrypt-linux-kernel/
osflux.pl — Copy Fail i kontekst poprzednich LPE 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ł