DirtyDecrypt: Krytyczna luka w Linux – publiczny exploit daje root

Publicznie dostępny exploit DirtyDecrypt uderza dokładnie tam, gdzie administratorzy Linuxa czują się (zwykle) najbezpieczniej: w jądro systemu. Nowa podatność jądra Linux, powiązana z CVE-2026-31635, umożliwia eskalację uprawnień Linux do poziomu root z konta zwykłego użytkownika – bez race condition, stabilnie i powtarzalnie. Po opublikowaniu Proof‑of‑Concept (PoC) na GitHubie ryzyko realnych ataków rośnie wykładniczo. To nie jest teoretyczny bug – to praktyczne narzędzie do przejmowania kontroli nad podatnymi serwerami.

Dla środowisk serwerowych, chmur, CI/CD, a także stacji developerskich opartych na rolling release (Fedora, Arch Linux, openSUSE Tumbleweed) ta luka DirtyDecrypt Linux oznacza realne zagrożenie: lokalny użytkownik, proces w kontenerze, a nawet napastnik z dostępem przez zhakowaną aplikację może zrobić root na jądrze z włączonym CONFIG_RXGK. Jeśli opierasz się na Linuxie w produkcji – musisz założyć, że każdy lokalny dostęp do systemu jest potencjalnie równy pełnemu przejęciu maszyny, dopóki nie zaktualizujesz jądra.

DirtyDecrypt – co się stało i kogo dotyczy?

DirtyDecrypt (znany też jako DirtyCBC) to nowa luka w jądrze Linux, powiązana z CVE-2026-31635 – lokalną podatnością typu privilege escalation, ocenioną na CVSS 7.5 (wysoka istotność). Błąd znajduje się w podsystemie RxRPC/RxGK, odpowiedzialnym za uwierzytelnianie i szyfrowanie w rozproszonych systemach plików (m.in. AFS – Andrew File System).

Kto jest zagrożony?

• Systemy z jądrem Linux, w którym skompilowano i włączono opcję CONFIG_RXGK.
• Dystrybucje śledzące blisko upstream i rolling release, m.in.:
  • Fedora
  • Arch Linux
  • openSUSE Tumbleweed
• Środowiska z jądrami w wersjach:
  • 6.16.1 do < 6.18.23
  • 6.19 do < 6.19.13
  • 7.0-rc1 – 7.0-rc7 (kandydaty wydań)

  według technicznej analizy DirtyDecrypt.

PILNE: exploit jest już publiczny i został potwierdzony jako działający przeciwko jądrze mainline i Fedorze. Oznacza to, że nie mówimy o “poczekajmy na malware”, tylko o realnym vektorze ataku dostępnych od ręki dla każdego.

Szczegóły techniczne ataku

Rdzeń problemu: brak COW guard i skażenie page cache

DirtyDecrypt wykorzystuje błąd w funkcji rxgk_decrypt_skb (oraz związanej z nią logice w rxgk_verify_response()), gdzie brakuje poprawnej ochrony typu copy-on-write (COW) przy obsłudze danych uwierzytelniających w RxGK.

W praktyce:

• Kernel akceptuje przewymiarowane odpowiedzi uwierzytelniające z sieci.
• Przez brak COW guard, nadmiarowe dane są zapisywane do pamięci używanej przez uprzywilejowane procesy lub do page cache plików, które powinny być tylko do odczytu.
• Może to dotyczyć kluczowych plików, takich jak /etc/shadow, /etc/sudoers czy binaria SUID (np. su, sudo).

Efekt jest podobny do wcześniejszych błędów CopyFail, DirtyFrag i Fragnesia (wszystkie LPE do root): napastnik może modyfikować zawartość plików uznawanych przez system za tylko do odczytu, ale na poziomie cache, bez zmiany ich kopii na dysku.

“But the outcome is the same: it allows unprivileged local attackers to modify read-only file contents in the kernel page cache and obtain root privileges.”

KRYTYCZNE: To nie jest exploit czasowy (race condition), ale stabilny, deterministyczny LPE – jeżeli spełniasz warunki konfiguracji, atak po prostu działa.

Od zwykłego usera do root – ścieżka ataku

Typowy scenariusz wykorzystania:

• Napastnik ma lokalny dostęp (konto użytkownika, shell przez podatną aplikację, kontener z możliwością interakcji z jądrem).
• Uruchamia exploit typu DirtyDecrypt, który wysyła specjalnie spreparowane pakiety do RxGK i wymusza zapis danych do page cache uprzywilejowanego pliku.
• Exploit “zatruwa” cache pliku SUID (np. /usr/bin/su) lub krytycznego pliku konfiguracyjnego (np. /etc/sudoers), wstrzykując swój kod lub otwierając nieograniczony dostęp.
• Przy kolejnym wywołaniu tego pliku system wykonuje już zmodyfikowaną wersję z pamięci, dając napastnikowi uprawnienia root.

W środowiskach multi‑tenant (np. serwery współdzielone, klastry CI/CD, VDI, serwery uczelniane) każdy lokalny użytkownik może stać się potencjalnym rootem dla całego systemu.

Sprawdź natychmiast, czy jesteś zagrożony

1. Zweryfikuj wersję jądra Linux

Na początek sprawdź wersję jądra:

uname -r

Jeśli wynik wpada w zakres:

• 6.16.1 – 6.18.22
• 6.19.0 – 6.19.12
• 7.0-rc1 – 7.0-rc7

– i jednocześnie używasz dystrybucji, która śledzi upstream (Fedora, Arch, openSUSE Tumbleweed), istnieje duże ryzyko podatności.

2. Sprawdź, czy jądro ma włączone CONFIG_RXGK

DirtyDecrypt dotyczy tylko jąder z włączonym CONFIG_RXGK.

Możesz to sprawdzić np. tak (w zależności od dystrybucji):

grep RXGK /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz | grep RXGK

Jeżeli zobaczysz:

CONFIG_RXGK=y

– system korzysta z RxGK i jest potencjalnie podatny, jeśli wersja jądra mieści się w zakresie podatnych wydań.

Ważne: nawet jeśli nie używasz AFS świadomie, część dystrybucji kompiluje wsparcie RxGK domyślnie, więc nie zakładaj, że “nie używamy AFS, więc jest bezpiecznie”.

3. Czy dostępne są łatki?

Według analiz technicznych, łatki zostały włączone do kernela po 25 kwietnia 2026. Nowsze wersje (np. ≥ 6.18.23, ≥ 6.19.13 i kolejne) oraz nowsze wersje dystrybucji powinny zawierać poprawki.

W niektórych środowiskach (szczególnie z custom kernelami) mogą jednak nie być jeszcze dostępne vendorowe paczki, więc konieczna jest ręczna weryfikacja changelogów jądra i komunikatów bezpieczeństwa dystrybutora.

Oryginalny materiał od @The Cyber Security Hub™ możesz zobaczyć poniżej:

Jak widać w powyższym materiale, społeczność bezpieczeństwa szybko reaguje na takie zagrożenia, co podkreśla wagę natychmiastowych działań.

Jak się chronić – kluczowe kroki zabezpieczenia

1. Aktualizacja jądra Linux – priorytet nr 1

PILNE: jeśli Twoje środowisko spełnia warunki podatności, aktualizacja jądra Linux to absolutny must‑do.

• Zaktualizuj kernel do wersji oznaczonej przez Twoją dystrybucję jako zawierającej poprawkę dla CVE-2026-31635.
• Na rolling release (Arch, openSUSE Tumbleweed, Fedora Rawhide) wykonaj pełne dist-upgrade i upewnij się, że system bootuje w nowym jądrze.
• W środowiskach produkcyjnych zaplanuj maintenance window, ale nie odkładaj aktualizacji “na kiedyś” – exploit jest publiczny.

Wskazówka: jeżeli stosujesz narzędzia typu livepatch, sprawdź, czy Twój vendor (np. Canonical, Red Hat, SUSE) dostarczył łatę livepatch dla tego CVE. Jeśli nie – pełny reboot w nowe jądro jest konieczny.

2. Ogranicz lokalny dostęp i uprzywilejowane konta

Nawet po załataniu warto wzmocnić ogólną postawę bezpieczeństwa:

• Minimalizuj liczbę kont z dostępem shell do serwerów (zwłaszcza bastionów, hostów CI/CD, węzłów Kubernetes).
• Oddzielaj środowiska (prod, stage, dev) na osobne hosty – nie pozwalaj developerom na shell na produkcji.
• Egzekwuj zasadę najmniejszych uprawnień (least privilege) także dla kont serwisowych i kontenerów.

3. Monitoring i wykrywanie – IOCs dla DirtyDecrypt

DirtyDecrypt to przede wszystkim lokalna eskalacja uprawnień Linux, więc klasyczne IOCs (hashy plików, domeny C2) będą zależeć od konkretnego malware. Możesz jednak szukać symptomów ataku:

• Nietypowe wywołania binariów SUID (np. su, sudo) tuż po aktywności podejrzanego użytkownika.
• Alerty EDR/HIDS wskazujące na anomalie w pamięci, zwłaszcza modyfikację page cache lub hookowanie binariów systemowych.
• Pojawienie się nowych kont użytkowników z uprawnieniami sudo, modyfikacje /etc/sudoers lub /etc/passwd//etc/shadow.
• Obecność plików o nazwach typu dirtydecrypt.c, poc.c lub skompilowanych binariów eksploitów w katalogach tymczasowych (/tmp, /dev/shm, home użytkowników).

Wskazówka: rozważ wdrożenie EDR dla Linux oraz centralnego logowania (SIEM), aby wykrywać nietypowe sekwencje: uruchomienie nieznanego binarium → wywołanie SUID → zmiana kontekstu na root.

4. Hardenowanie kernela i powierzchni ataku

Poza samym patchem warto:

• Przeglądnąć konfigurację jądra – jeżeli nie potrzebujesz AFS/RxGK, rozważ build kernela bez CONFIG_RXGK w środowiskach wrażliwych.
• Korzystać z mechanizmów takich jak:
  • SELinux / AppArmor
  • seccomp i ograniczanie syscalls w kontenerach
  • blokowanie niepotrzebnych modułów kernela
• Regularnie audytować ustawienia SUID i usługi dostępne dla lokalnych użytkowników.

Ciekawostka: cała rodzina błędów CopyFail / DirtyFrag / Fragnesia / DirtyDecrypt pokazuje, że page cache stał się krytycznym wektorem ataku na Linuxa – jeśli nie można bezpośrednio zapisać pliku na dysku, napastnicy próbują “zatruc” jego wersję w pamięci.

Co to oznacza dla przyszłości bezpieczeństwa serwerów Linux?

DirtyDecrypt dołącza do niepokojącej serii błędów w jądrze Linux, które wszystkie sprowadzają się do jednego problemu: jeśli nieuprzywilejowany proces może w kontrolowany sposób modyfikować page cache uprzywilejowanego pliku, root jest w zasięgu ręki. To fundamentalne wyzwanie dla modelu bezpieczeństwa systemu, który przez lata zakładał, że “read‑only” naprawdę oznacza “niezmienialne” dla zwykłego użytkownika.

Dla administratorów i architektów oznacza to konieczność zmiany myślenia:

• przyjmowanie, że lokalny dostęp ≈ potencjalny root, dopóki jądro nie zostanie załatane;
• traktowanie aktualizacji jądra Linux nie jako “kiedyś przy okazji”, ale jako kluczowy element vulnerability management – na równi z łataniem aplikacji webowych;
• większy nacisk na segmentację, least privilege, monitoring i EDR dla workloadów Linux.

Twoje kolejne kroki – podsumowanie działań

• Natychmiast: sprawdź wersję jądra i konfigurację CONFIG_RXGK na wszystkich serwerach i stacjach developerskich.
• W ciągu najbliższych dni: zaplanuj i wykonaj aktualizację jądra do wersji z łatą na CVE-2026-31635, zwłaszcza w środowiskach Fedora, Arch, openSUSE Tumbleweed.
• Krótki termin: ogranicz lokalny dostęp, przeaudytuj konta, polityki sudo, binaria SUID i logi pod kątem nietypowych eskalacji uprawnień.
• Średni termin: wzmocnij polityki hardeningu, wdroż EDR/SIEM dla Linux, rozważ minimalne kernela bez nieużywanych podsystemów takich jak RxGK.

DirtyDecrypt pokazuje, że bezpieczeństwo serwerów Linux nie jest dane raz na zawsze. Jeżeli Twoja infrastruktura stoi na jądrze Linux – to jest moment, żeby sprawdzić czy jesteś zagrożony i potraktować łatki kernela tak samo poważnie, jak krytyczne dziury w aplikacjach webowych. Zabezpiecz swoje systemy już dziś. Każda minuta opóźnienia zwiększa ryzyko.