DirtyClone (CVE-2026-43503): nowa luka w Linuxie umożliwia przejęcie roota bez śladu na dysku

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

DirtyClone to nowo opisana lokalna podatność eskalacji uprawnień w jądrze Linux, oznaczona jako CVE-2026-43503. Błąd należy do rodziny problemów DirtyFrag i wynika z nieprawidłowej obsługi pamięci współdzielonej między cache plików a buforami sieciowymi jądra.

W praktyce oznacza to możliwość zmodyfikowania uprzywilejowanego pliku wykonywalnego wyłącznie w pamięci operacyjnej, bez trwałej zmiany jego zawartości na dysku. Taki scenariusz może doprowadzić do uzyskania uprawnień root przez lokalnego, nieuprzywilejowanego użytkownika.

W skrócie

DirtyClone umożliwia lokalną eskalację uprawnień do roota na podatnych systemach Linux.
Podatność otrzymała ocenę CVSS 8.8 i została publicznie opisana 25 czerwca 2026 roku.
Atak wykorzystuje utratę znacznika bezpieczeństwa informującego, że bufor sieciowy odwołuje się do współdzielonej pamięci powiązanej z plikiem.
Skutkiem może być nadpisanie obrazu binarnego pliku systemowego w RAM, bez pozostawienia śladu na dysku.
Największe ryzyko dotyczy środowisk wieloużytkownikowych, kontenerowych i chmurowych.

Kontekst / historia

DirtyClone nie jest odosobnionym przypadkiem, lecz kolejnym wariantem szerszej klasy błędów w stosie sieciowym jądra Linux. Wcześniejsze luki, takie jak Copy Fail, DirtyFrag oraz Fragnesia, bazowały na podobnym mechanizmie: jądro dopuszczało sytuację, w której pamięć pochodząca z page cache pliku była traktowana jak zwykły bufor pakietu sieciowego.

Dotychczasowe poprawki miały wymuszać bezpieczne kopiowanie danych przed operacjami modyfikującymi zawartość bufora. Problem polegał jednak na tym, że nie wszystkie ścieżki kodu zostały właściwie zabezpieczone. DirtyClone pokazał, że w procesie klonowania pakietów nadal można było utracić istotny znacznik metadanych i ponownie otworzyć drogę do nadużycia.

W efekcie mamy do czynienia nie z pojedynczą anomalią, lecz z kolejnym dowodem na to, że granica między pamięcią plików a pamięcią pakietów w jądrze Linux pozostaje wrażliwym obszarem bezpieczeństwa.

Analiza techniczna

Sednem podatności jest błędne zachowanie struktur sk_buff, które reprezentują pakiety sieciowe w jądrze. W poprawnym modelu bezpieczeństwa pamięć mapowana z pliku i pamięć wykorzystywana przez stos sieciowy powinny pozostawać odseparowane. Rodzina DirtyFrag łamie to założenie, pozwalając doprowadzić do sytuacji, w której pakiet sieciowy odwołuje się bezpośrednio do strony page cache należącej do pliku wykonywalnego.

Przykładowy scenariusz zaczyna się od zmapowania uprzywilejowanego pliku binarnego, takiego jak /usr/bin/su, do pamięci współdzielonej tylko do odczytu. Następnie atakujący korzysta z mechanizmów vmsplice i splice, aby powiązać tę pamięć z buforem pakietu bez kopiowania danych. W ten sposób zawartość page cache zaczyna pełnić równocześnie rolę nośnika danych pakietowych.

Kolejny etap obejmuje skierowanie pakietu przez lokalnie przygotowaną ścieżkę IPsec. W części środowisk do zbudowania takiego scenariusza może wystarczyć dostęp do możliwości sieciowych osiągalnych z poziomu przestrzeni nazw użytkownika. Atak wykorzystuje lokalny tunel loopback oraz odpowiednie reguły routingu i filtrowania, aby jądro weszło w podatną ścieżkę przetwarzania.

W wariancie DirtyClone problem pojawia się podczas tworzenia sklonowanego bufora pakietu. Oryginalny pakiet zachowuje metadane wskazujące na współdzielony fragment pamięci, ale jego klon może utracić znacznik SKBFL_SHARED_FRAG. To właśnie ta utrata sprawia, że późniejsze operacje kryptograficzne nie wymuszają mechanizmu copy-on-write.

Gdy pakiet trafia do ścieżki przetwarzania IPsec, odszyfrowanie wykonywane jest bezpośrednio w tym samym buforze pamięci. Jeżeli bufor wskazuje faktycznie na stronę page cache należącą do pliku wykonywalnego, odszyfrowane dane nadpisują obraz tego pliku w pamięci RAM. Atakujący nie uzyskuje pełnej dowolności zapisu, ale dzięki kontroli nad materiałem kryptograficznym, układem pakietu i wybranymi parametrami może wprowadzić przewidywalne zmiany w krytycznych offsetach. To może wystarczyć do podmiany logiki uwierzytelniania i uruchomienia zmodyfikowanego binarium z uprawnieniami roota.

Najbardziej niepokojącą cechą DirtyClone jest to, że modyfikacja zachodzi wyłącznie w pamięci operacyjnej. Integralność plików na dysku pozostaje formalnie nienaruszona, co znacząco utrudnia wykrycie incydentu przez klasyczne mechanizmy monitorowania.

Konsekwencje / ryzyko

Z perspektywy operacyjnej DirtyClone to bardzo poważna podatność lokalna. Jej skuteczne wykorzystanie może prowadzić do pełnej eskalacji uprawnień na hoście, a w konsekwencji do przejęcia kontroli nad systemem, wyłączenia zabezpieczeń, kradzieży poświadczeń oraz manipulacji procesami i kontenerami.

Największe zagrożenie dotyczy systemów wieloużytkownikowych, serwerów CI/CD, hostów kontenerowych, środowisk chmurowych oraz klastrów, w których lokalny użytkownik lub proces może uzyskać szerokie możliwości konfigurowania stosu sieciowego. Szczególnie wrażliwe są instalacje z aktywnymi nieuprzywilejowanymi przestrzeniami nazw użytkownika.

Problemem jest także wysoka trudność detekcji. Atak nie wymaga modyfikacji plików na dysku, może nie pozostawiać czytelnych śladów w logach jądra i nie musi wyzwalać alertów systemów monitorujących integralność plików. Organizacja może więc błędnie uznać host za nienaruszony, mimo że doszło już do kompromitacji na poziomie root.

Rekomendacje

Najważniejszym działaniem naprawczym pozostaje aktualizacja jądra Linux do wersji zawierającej komplet poprawek dla całej rodziny DirtyFrag, w tym CVE-2026-43503. Nie należy zakładać, że wcześniejsze łatki dla pokrewnych błędów są wystarczające, jeśli dostawca dystrybucji nie potwierdził wdrożenia pełnego backportu.

Jeżeli natychmiastowe wdrożenie poprawki nie jest możliwe, warto ograniczyć powierzchnię ataku poprzez działania tymczasowe:

wyłączenie nieuprzywilejowanych user namespaces tam, gdzie jest to operacyjnie możliwe,
ograniczenie i monitorowanie uzyskiwania CAP_NET_ADMIN,
przegląd konfiguracji kontenerów i hostów pod kątem nadmiernych uprawnień sieciowych,
rozważenie blokady nieużywanych modułów i funkcji powiązanych z IPsec,
monitorowanie nietypowego użycia narzędzi takich jak unshare, ip xfrm czy mechanizmów filtrowania pakietów.

W obszarze detekcji organizacje powinny wyjść poza klasyczne monitorowanie integralności plików na dysku. Pomocne będą:

telemetria EDR skupiona na nietypowych działaniach użytkowników lokalnych,
analiza zdarzeń związanych z namespace’ami, XFRM i netfilter,
weryfikacja wersji kernela oraz faktycznego zakresu backportów bezpieczeństwa,
segmentacja dostępu i ograniczanie możliwości lokalnego uruchamiania kodu na hostach współdzielonych.

W środowiskach, które niedawno dopuszczały wykonywanie kodu przez nieufnych użytkowników lokalnych, warto rozważyć dodatkową ocenę incydentową. W przypadku podejrzenia wykorzystania luki bezpiecznym założeniem powinno być traktowanie hosta jako potencjalnie przejętego z uprawnieniami root.

Podsumowanie

DirtyClone potwierdza, że rodzina DirtyFrag to nie pojedyncza luka, lecz cała klasa błędów wynikających z niejednoznacznego rozdzielenia pamięci plików i pamięci pakietów w jądrze Linux. CVE-2026-43503 pokazuje, jak utrata jednego znacznika metadanych może otworzyć drogę do przejęcia roota bez trwałej modyfikacji pliku na dysku.

Dla zespołów bezpieczeństwa oznacza to konieczność szybkiego patchowania kernela, ograniczania zbędnych uprawnień lokalnych oraz rozwijania mechanizmów detekcji zdolnych wykrywać nadużycia zachodzące wyłącznie w pamięci operacyjnej.