Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Dirty Frag to nowa klasa podatności lokalnej eskalacji uprawnień w jądrze Linuksa, która może umożliwić nieuprzywilejowanemu użytkownikowi przejęcie pełnych uprawnień roota. Problem dotyczy mechanizmów zapisu do page cache i wynika z połączenia błędów obecnych w ścieżkach przetwarzania xfrm-ESP oraz RxRPC.
Na tle wcześniejszych podatności tej rodziny Dirty Frag wyróżnia się wysoką niezawodnością oraz brakiem konieczności wykorzystania klasycznego wyścigu czasowego. To sprawia, że exploit może być bardziej praktyczny operacyjnie i łatwiejszy do wykorzystania w rzeczywistych scenariuszach naruszeń.
W skrócie
- Dirty Frag to łańcuch exploitów prowadzących do lokalnej eskalacji uprawnień w Linuksie.
- Wykorzystuje dwa prymitywy zapisu do page cache: xfrm-ESP oraz RxRPC.
- Jeden z komponentów oznaczono jako CVE-2026-43284, a drugi jako CVE-2026-43500.
- Podatność dotyczyła m.in. systemów opartych o Ubuntu, RHEL, Fedora, AlmaLinux, CentOS Stream i openSUSE.
- W momencie ujawnienia dostępny był działający proof-of-concept, a obserwowano również ograniczone próby wykorzystania podobnych technik.
Kontekst / historia
Dirty Frag jest opisywane jako kolejny etap ewolucji błędów związanych z integralnością danych w page cache jądra, po takich przypadkach jak Dirty Pipe czy Copy Fail. Wspólny mianownik tych podatności stanowi możliwość modyfikacji danych, które w normalnych warunkach powinny pozostawać chronione przed zapisem przez nieuprzywilejowanego użytkownika.
Według publicznych analiz podatny kod związany z xfrm-ESP trafił do jądra w styczniu 2017 roku, natomiast komponent RxRPC pojawił się w czerwcu 2023 roku. Problem został zgłoszony maintainterom jądra 30 kwietnia 2026 roku, a szybkie ujawnienie szczegółów technicznych oraz kodu exploitacyjnego zwiększyło presję na dostawców dystrybucji i zespoły bezpieczeństwa.
Istotne jest również to, że wcześniejsze obejścia stosowane wobec pokrewnych błędów, takie jak ograniczanie modułu algif_aead, nie rozwiązują problemu Dirty Frag. Organizacje polegające na starych mitigacjach mogły więc błędnie uznać swoje środowiska za zabezpieczone.
Analiza techniczna
Technicznie Dirty Frag wykorzystuje błędne operacje na stronach pamięci powiązanych z page cache, które nie pozostają wyłącznie pod kontrolą jądra. W określonych ścieżkach szybkiego przetwarzania odszyfrowanie lub operacje wejścia-wyjścia zachodzą bezpośrednio na stronach backingowych, do których odwołania może nadal posiadać proces nieuprzywilejowany.
Pierwszy wariant, określany jako xfrm-ESP Page-Cache Write, dotyczy subsystemu IPsec/XFRM. Zapewnia ograniczony, ale praktyczny prymityw zapisu do page cache. W wielu scenariuszach jego wykorzystanie wymaga możliwości tworzenia user namespace, choć zależy to od konfiguracji dystrybucji i polityki bezpieczeństwa systemu.
Drugi wariant, RxRPC Page-Cache Write, nie wymaga uprawnienia do tworzenia user namespace, ale jego skuteczność zależy od obecności i załadowania modułu rxrpc. W praktyce oznacza to, że ograniczenia jednego wektora mogą być kompensowane przez drugi, co znacząco zwiększa liczbę potencjalnie podatnych konfiguracji.
To połączenie dwóch odmiennych ścieżek eksploatacji czyni Dirty Frag szczególnie niebezpiecznym. Brak zależności od race condition, relatywnie wysoka stabilność działania i możliwość użycia po uzyskaniu zwykłego konta użytkownika obniżają próg wejścia dla napastnika.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem Dirty Frag jest możliwość lokalnej eskalacji uprawnień do roota. Jeśli atakujący zdobędzie wstępny dostęp do hosta, na przykład przez słabe hasło, błędną konfigurację usługi lub podatną aplikację webową, może wykorzystać ten błąd do pełnego przejęcia systemu.
Ryzyko jest szczególnie istotne w środowiskach wieloużytkownikowych, serwerach aplikacyjnych, systemach CI/CD, hostach administracyjnych oraz infrastrukturze współdzielonej z dostawcami zewnętrznymi. W środowiskach kontenerowych podatność może też stanowić element szerszego łańcucha prowadzącego do ucieczki z kontenera lub kompromitacji systemu bazowego.
Dodatkowym problemem jest dostępność działającego proof-of-concept. W praktyce oznacza to, że luka nie pozostaje wyłącznie zagrożeniem teoretycznym, lecz może szybko zostać zaadaptowana do działań po uzyskaniu początkowego dostępu.
Rekomendacje
Najważniejszym działaniem powinno być szybkie śledzenie dostępności poprawek dla używanych wersji jądra oraz ich wdrożenie zgodnie z procesem patch management. Należy monitorować komunikaty producentów dystrybucji, ponieważ status podatności i dostępność aktualizacji mogą się różnić w zależności od wariantu kernela i kanału wsparcia.
Do czasu pełnego załatania środowiska warto rozważyć ograniczenie lub blokadę modułów esp4, esp6 oraz rxrpc, o ile nie są one wymagane operacyjnie. Tego typu mitigacja powinna jednak zostać poprzedzona analizą wpływu na usługi sieciowe, w szczególności na wdrożenia IPsec.
Dobrą praktyką jest także ograniczenie możliwości tworzenia user namespace przez nieuprzywilejowanych użytkowników tam, gdzie nie jest to niezbędne biznesowo. Choć nie eliminuje to całego problemu, może utrudnić wykorzystanie jednego z wariantów exploitu.
Od strony detekcyjnej warto monitorować:
- nietypowe użycie poleceń związanych z podnoszeniem uprawnień,
- nagłe uruchamianie nieznanych binariów ELF,
- modyfikacje wrażliwych plików systemowych,
- podejrzane aktywności po zalogowaniu przez SSH,
- korelację zdarzeń pomiędzy wstępnym dostępem a działaniami post-exploitation.
Podsumowanie
Dirty Frag pokazuje, że błędy związane z obsługą page cache w jądrze Linuksa nadal pozostają groźną i praktyczną klasą podatności. Połączenie wariantów xfrm-ESP i RxRPC zwiększa skuteczność eksploatacji oraz rozszerza listę podatnych konfiguracji, co podnosi ryzyko dla wielu środowisk produkcyjnych.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że lokalne podatności jądra nie powinny być traktowane jako zagrożenia drugiego planu. W nowoczesnych incydentach właśnie taki błąd często staje się etapem, który zamienia ograniczone naruszenie w pełną kompromitację systemu.