Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
DirtyDecrypt to nowa lokalna podatność eskalacji uprawnień w jądrze Linux, oznaczona jako CVE-2026-31635. Luka wynika z błędu klasy page cache write primitive, związanego z nieprawidłową ochroną mechanizmu copy-on-write w ścieżce deszyfrowania pakietów w podsystemie rxgk. W praktyce może to pozwolić lokalnemu atakującemu na modyfikację danych w pamięci współdzielonej lub w pamięci podręcznej uprzywilejowanych plików, a w konsekwencji na uzyskanie uprawnień roota.
W skrócie
Największe znaczenie tej podatności wynika z publicznego udostępnienia działającego proof-of-concept, który obniża próg wejścia dla potencjalnych napastników. Problem nie dotyczy wszystkich dystrybucji Linuxa, lecz przede wszystkim tych, które wykorzystują jądra skompilowane z włączoną opcją CONFIG_RXGK. Wśród wskazywanych środowisk znajdują się między innymi Fedora, Arch Linux oraz openSUSE Tumbleweed, podczas gdy typowe instalacje Ubuntu i Debiana nie są zwykle uznawane za podatne w standardowej konfiguracji.
- Podatność umożliwia lokalną eskalację uprawnień.
- Publiczny PoC zwiększa ryzyko praktycznego wykorzystania.
- Kluczowe znaczenie ma obecność opcji CONFIG_RXGK.
- Zagrożone są szczególnie systemy wieloużytkownikowe i hosty kontenerowe.
Kontekst / historia
DirtyDecrypt wpisuje się w szerszą serię błędów bezpieczeństwa związanych z naruszeniem integralności page cache w jądrze Linux. Badacze wiążą ją z rodziną podatności podobnych do wcześniejszych przypadków, takich jak Copy Fail, Dirty Frag czy Fragnesia. Wspólną cechą tych problemów jest możliwość modyfikacji danych, które zgodnie z założeniami izolacji pamięci powinny pozostawać odseparowane od innych procesów i kontekstów wykonania.
Luka została nagłośniona w okresie zwiększonego zainteresowania badaczy bezpieczeństwa zagadnieniami związanymi z pamięcią współdzieloną i obsługą page cache w jądrze. Choć wskazywano, że problem może być powiązany z wcześniej naprawianymi błędami, publikacja działającego kodu PoC szybko podniosła rangę zagrożenia. Szczególne obawy dotyczą środowisk, w których atakujący może już uzyskać ograniczony dostęp lokalny, na przykład przez konto użytkownika, powłokę w systemie współdzielonym lub kontener uruchomiony na podatnym hoście.
Analiza techniczna
Źródłem podatności jest funkcja rxgk_decrypt_skb(), odpowiedzialna za obsługę deszyfrowania przychodzących buforów socketów w podsystemie rxgk. Kluczowy problem polega na tym, że podczas operacji zapisu jądro nie zapewnia właściwej ochrony copy-on-write dla współdzielonych stron pamięci. W bezpiecznym modelu przed zapisem powinna zostać utworzona prywatna kopia strony, tak aby zmiany wykonane w jednym kontekście nie wpływały na dane należące do innych procesów lub do page cache powiązanego z plikami systemowymi.
W DirtyDecrypt ten mechanizm nie działa prawidłowo, co otwiera drogę do skierowania zapisu na stronę powiązaną z wrażliwym zasobem. W zależności od scenariusza eksploatacji może to umożliwić modyfikację krytycznych plików, takich jak polityki kontroli dostępu, konfiguracje sudo czy binaria oznaczone bitem SUID. Tego typu zmiany mogą następnie zostać wykorzystane do przejęcia pełnych uprawnień administracyjnych.
Z technicznego punktu widzenia nie jest to jedynie błąd pojedynczej aplikacji userspace, ale naruszenie podstawowych założeń izolacji pamięci na poziomie jądra. To właśnie dlatego luka ma szczególnie wysoki ciężar operacyjny i powinna być traktowana jako realny wektor post-exploitation, a nie jedynie ciekawostka badawcza.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją DirtyDecrypt jest możliwość lokalnego podniesienia uprawnień do poziomu root. Oznacza to, że nawet ograniczony dostęp do systemu może w sprzyjających warunkach doprowadzić do pełnego przejęcia hosta. Szczególnie narażone są środowiska wieloużytkownikowe, serwery współdzielone, zaplecza deweloperskie oraz infrastruktura, w której użytkownicy lub procesy mają możliwość uruchamiania własnego kodu.
Ryzyko dodatkowo wzrasta w środowiskach kontenerowych. Jeśli podatny pozostaje sam host, luka może zostać wykorzystana jako element ucieczki z izolowanego środowiska i przejęcia kontroli nad systemem bazowym. W efekcie lokalna podatność jednego użytkownika lub kontenera może przełożyć się na zagrożenie dla wielu usług, danych i tenantów działających na tym samym węźle.
- Możliwość uzyskania uprawnień roota przez lokalnego użytkownika.
- Wyższe ryzyko w systemach z dostępem shell dla wielu osób.
- Potencjalny wpływ na hosty uruchamiające kontenery.
- Skrócony czas reakcji obronnej ze względu na publiczny PoC.
Rekomendacje
Najważniejszym krokiem jest ustalenie, czy używane jądra zostały skompilowane z włączoną opcją CONFIG_RXGK. To właśnie ta cecha konfiguracji pozwala ocenić, czy dane środowisko znajduje się w realnej strefie ryzyka. Organizacje powinny niezwłocznie przeprowadzić inwentaryzację podatnych systemów, zwłaszcza jeśli korzystają z Fedory, Arch Linuxa, openSUSE Tumbleweed lub niestandardowych buildów kernela.
Z perspektywy operacyjnej zalecane są następujące działania:
- pilne wdrożenie aktualizacji jądra oraz zaleceń publikowanych przez dostawcę dystrybucji,
- weryfikacja konfiguracji kernela w obrazach bazowych, pipeline’ach CI/CD i środowiskach testowych,
- ograniczenie lokalnego dostępu interaktywnego dla nieuprzywilejowanych użytkowników,
- monitorowanie nietypowych zmian w plikach systemowych, konfiguracjach sudo i plikach SUID,
- przegląd bezpieczeństwa hostów kontenerowych oraz dodatkowa segmentacja wrażliwych workloadów,
- wdrożenie działań kompensujących tam, gdzie poprawki nie mogą zostać zastosowane natychmiast.
W organizacjach o podwyższonym profilu ryzyka warto także tymczasowo ograniczyć możliwość uruchamiania niezweryfikowanego kodu lokalnie oraz zredukować liczbę kont z dostępem shell. Tego rodzaju środki nie usuwają samej podatności, ale mogą znacząco utrudnić jej praktyczne wykorzystanie.
Podsumowanie
DirtyDecrypt pokazuje, że błędy związane z page cache i ochroną copy-on-write nadal należą do najbardziej niebezpiecznych klas podatności w jądrze Linux. Choć problem nie obejmuje wszystkich dystrybucji, połączenie możliwości uzyskania roota i publicznie dostępnego kodu PoC czyni tę lukę poważnym zagrożeniem dla podatnych środowisk. Administratorzy powinni jak najszybciej ustalić, czy ich systemy wykorzystują CONFIG_RXGK, a następnie wdrożyć poprawki i działania ograniczające ryzyko.
Źródła
- Security Affairs — https://securityaffairs.com/192436/uncategorized/dirtydecrypt-poc-released-for-yet-another-linux-flaw.html
- NVD: CVE-2026-31635 — https://nvd.nist.gov/vuln/detail/CVE-2026-31635
- DirtyDecrypt PoC Repository — https://github.com/zellic/DirtyDecrypt
- Moselwal — DirtyDecrypt technical analysis — https://moselwal.com/dirtydecrypt-linux-kernel-lpe/
- Kernel Config Reference: CONFIG_RXGK — https://www.kernelconfig.io/config_rxgk