Dirty Frag: nowa podatność Local Privilege Escalation w Linuxie. Co to jest, jak działa i jak się zabezpieczyć

7 maja 2026 r. publicznie ujawniono nową, bardzo poważną podatność w jądrze Linuxa, nazwaną Dirty Frag. To luka typu Local Privilege Escalation (LPE), czyli taka, która pozwala użytkownikowi z lokalnym dostępem do systemu podnieść uprawnienia do roota. Badacz Hyunwoo Kim opisał Dirty Frag jako „universal Linux LPE”, ponieważ przygotowany exploit ma działać na większości głównych dystrybucji.

Najgorsza wiadomość jest taka, że ujawnienie nastąpiło po złamaniu embarga, więc w momencie disclosure nie było jeszcze przydzielonego numeru CVE ani gotowych poprawek od dystrybucji. To nie jest typ sytuacji „spokojnie, patch już leci przez repo”. To jest raczej klasyczne: luka publiczna, PoC publiczny, a administratorzy muszą najpierw gasić pożar, a dopiero potem porządkować serwery.

Co to jest Dirty Frag

Dirty Frag to nie jedna drobna literówka w kernelu, tylko łańcuch dwóch podatności w sieciowych podsystemach Linuksa, które razem pozwalają osiągnąć roota. W opisie na oss-security badacz wskazuje wprost, że exploit łączy dwa osobne błędy: xfrm-ESP Page-Cache Write oraz RxRPC Page-Cache Write.

To ważne, bo Dirty Frag nie jest prostą kopią wcześniejszego Copy Fail. Jest z tej samej rodziny „dirty” błędów opartych o nieprawidłowy zapis do page cache, ale działa w innym fragmencie kernela i omija część wcześniejszych intuicji obronnych. Autor write-upu zaznacza wprost, że nawet jeśli ktoś zastosował znaną mitigację dla Copy Fail, czyli blokadę algif_aead, to system nadal może być podatny na Dirty Frag.

Czy Dirty Frag ma już numer CVE

Na dziś, czyli 8 maja 2026 r., nie – Dirty Frag nie ma jeszcze oficjalnie przydzielonego numeru CVE. Openwallowy disclosure mówi wprost, że po złamaniu embarga „no patches or CVEs exist”, a Red Hat w swoim bulletinie potwierdza, że te błędy „have not yet been assigned a CVE by upstream”. CloudLinux również oznacza temat jako CVE Pending.

Czyli mówiąc bez owijania: to jest realna luka, publicznie ujawniona, z działającym PoC, ale jeszcze bez finalnego numeru CVE. Sam brak numeru CVE nie zmniejsza ryzyka ani o milimetr. To tylko znaczy, że biurokracja jeszcze nie dogoniła rzeczywistości.

Jak działa Dirty Frag

Sedno problemu polega na tym, że kernel wykonuje operacje „in-place” na danych osadzonych w fragmencie skb, który może wskazywać na stronę page cache, do której zwykły użytkownik ma tylko odczyt. W praktyce oznacza to, że odpowiednio przygotowana ścieżka z splice() może doprowadzić do modyfikacji page cache w RAM, a potem do wykorzystania tego do eskalacji uprawnień. Autor technicznego opisu podkreśla, że potem kolejne odczyty pliku widzą już zmodyfikowaną wersję z pamięci.

W wariancie xfrm-ESP problem dotyczy ścieżki wejściowej ESP w IPv4/IPv6, gdzie in-place decryption potrafi ominąć oczekiwane kopiowanie do prywatnego bufora kernela. W wariancie RxRPC podobny efekt osiąga się przez in-place decrypt pierwszych bajtów payloadu. Opis techniczny wskazuje, że to właśnie połączenie tych dwóch wariantów daje bardzo szeroką „przenośność” exploitu między dystrybucjami.

Najbardziej nieprzyjemne w tej klasie błędów jest to, że to nie jest delikatny wyścig z timingiem. Badacz opisuje Dirty Frag jako deterministyczny błąd logiczny, bez race condition, z wysoką skutecznością i bez paniki kernela przy nieudanej próbie. Czyli stary, dobry koszmar administratora: działa stabilnie, daje roota i niekoniecznie zostawia widowiskowe gruzowisko.

Dlaczego Dirty Frag nazwano „Universal Linux LPE”

Bo exploit pokrywa wzajemnie ślepe plamy obu wariantów. Write-up wyjaśnia to bardzo jasno: wariant xfrm-ESP jest obecny na większości dystrybucji, ale wymaga możliwości utworzenia przestrzeni nazw użytkownika (unshare(CLONE_NEWUSER)). Z kolei wariant RxRPC nie wymaga takiego uprawnienia, ale sam moduł rxrpc.ko nie jest wszędzie obecny. Na przykład autor wskazuje, że domyślna instalacja RHEL 10.1 nie dostarcza rxrpc.ko, podczas gdy na Ubuntu moduł bywa ładowany domyślnie. Dzięki temu exploit najpierw próbuje jednego wektora, a jeśli ten zawiedzie, przechodzi do drugiego.

To właśnie dlatego Dirty Frag nie jest „niszową ciekawostką dla jednej gałęzi kernela”, tylko problemem szerokim operacyjnie. AlmaLinux napisał wprost, że „every supported AlmaLinux release is affected”, a Red Hat potwierdził wpływ na RHEL 8, 9 i 10 oraz OpenShift 4.

Kogo dotyczy zagrożenie

Najbardziej zagrożone są systemy, na których nieuprzywilejowany użytkownik może uruchomić lokalny kod. To mogą być:

• serwery wieloużytkownikowe,
• hosty z CI/CD runnerami,
• środowiska z kontenerami i buildami,
• serwery aplikacyjne, gdzie atakujący może zdobyć shell,
• maszyny developerskie i testowe z luźną polityką dostępu.

Red Hat w swoim bulletinie podkreśla właśnie, że chodzi o użytkownika z lokalnym kontem, a CloudLinux pisze wręcz, że działający publiczny PoC pozwala „any unprivileged local user” uzyskać roota jednym poleceniem.

To nie jest więc podatność typu „wchodzę z internetu bez logowania przez jeden port”. Ale jeśli napastnik zdobył już foothold — przez aplikację webową, słabe konto, błąd w panelu, źle odizolowany kontener albo runner — Dirty Frag może być kolejnym krokiem do pełnego przejęcia hosta.

Jak sprawdzić, czy system może być podatny

Tu trzeba powiedzieć uczciwie: na dziś nie ma jeszcze prostego vendorowego „patched / not patched” po numerze CVE, bo CVE jeszcze nie istnieje. Trzeba więc sprawdzać warunki podatności i stan mitigacji.

1. Sprawdź wersję kernela i advisory dostawcy

Na początek:

uname -r
cat /etc/os-release

Sama wersja kernela nie wystarczy do pełnej diagnozy, ale to punkt wyjścia do porównania z advisory dystrybucji. Red Hat, AlmaLinux i CloudLinux już opublikowali komunikaty statusowe.

2. Sprawdź obecność i stan modułów używanych przez exploit

Doraźna mitigacja opiera się na blokadzie esp4, esp6 i rxrpc, więc praktycznie warto sprawdzić:

lsmod | egrep '^(esp4|esp6|rxrpc)\b'
modinfo esp4 2>/dev/null | head
modinfo esp6 2>/dev/null | head
modinfo rxrpc 2>/dev/null | head

Jeśli moduły istnieją i mogą się ładować, jesteś bliżej warunków potrzebnych do wykorzystania luki. Sam brak załadowania w tej chwili nie daje pełnego spokoju, bo exploit może je autoloadować. Openwall i CloudLinux opisują to wprost.

3. Sprawdź, czy włączona jest blokada modułów

cat /etc/modprobe.d/dirtyfrag.conf

Jeśli plik istnieje i zawiera wpisy blokujące esp4, esp6 i rxrpc, to doraźna mitigacja została wdrożona. To nie jest jeszcze pełny patch kernela, ale jest to realna bariera utrudniająca wykorzystanie.

4. Oceń, czy host potrzebuje IPsec

To bardzo ważne, bo blokowanie esp4 i esp6 może zepsuć IPsec, w tym tunele oparte o strongSwan lub Libreswan. CloudLinux ostrzega przed tym wprost, a komentarze na LWN też zwracają uwagę, że IPsec będzie skutkiem ubocznym takiej mitigacji.

5. Sprawdź politykę user namespaces

Wariant xfrm-ESP według technicznego opisu wymaga możliwości unshare(CLONE_NEWUSER). Możesz wstępnie sprawdzić politykę systemu, np. na distro, które to ograniczają. Nie daje to pełnej gwarancji bezpieczeństwa, bo exploit ma też wariant RxRPC, ale pomaga w ocenie ekspozycji. Write-up podkreśla, że właśnie dlatego exploit łączy oba wektory.

Jak się zabezpieczyć teraz

Doraźna mitigacja

Na dziś najczęściej rekomendowana tymczasowa ochrona wygląda tak:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Taką komendę podał sam autor disclosure na oss-security, a CloudLinux i ich KB powtarzają ją jako natychmiastowy workaround.

Po wdrożeniu poprawionego kernela możesz to cofnąć:

sudo rm /etc/modprobe.d/dirtyfrag.conf

To znowu nie jest docelowe leczenie, tylko tymczasowa blokada.

Ważne ostrzeżenie: IPsec może przestać działać

Jeśli host:

• terminuje tunele IPsec,
• routuje IPsec,
• używa strongSwan,
• używa Libreswan,

to powyższa mitigacja może mu po prostu odciąć tę funkcję. CloudLinux napisał to bardzo jasno. Na typowym serwerze hostingowym jest to zwykle akceptowalne, ale na gatewayu VPN już niekoniecznie.

Jak załatać Dirty Frag

Tu sytuacja jest trochę przewrotna.

Stan na dziś

• CVE jeszcze nie ma.
• Vendorowe paczki nie wszędzie są już gotowe, ale część dostawców już pracuje nad wydaniami.
• Patch upstreamowy istnieje i został już scalony do drzewa netdev, co potwierdzają CloudLinux i techniczny write-up.

Co robi patch

Według technicznego opisu finalny patch oznacza wspólne fragmenty pochodzące z splice jako SKBFL_SHARED_FRAG, a następnie wymusza właściwą ścieżkę copy-on-write w ESP input. W skrócie: kernela przestaje traktować zewnętrznie przypięte strony page cache jak bezpieczny bufor do in-place modyfikacji.

Co robić operacyjnie

• AlmaLinux: poprawka była już „ready for testing” 7 maja 2026 r.
• CloudLinux: poprawione kernele i KernelCare livepatch były w build/test; dla CL9/CL10 miało to iść ścieżką kernela AlmaLinux, a dla CL7h/CL8 – przez rebuild CloudLinux.
• Red Hat: temat oznaczony jako ongoing, z przyspieszonym wydaniem poprawek, ale bez natychmiastowej pełnej instrukcji mitigacyjnej na stronie bulletinu.

Czyli praktycznie: monitoruj advisory swojego vendora i instaluj poprawiony kernel od razu, gdy się pojawi. To nie jest temat na „kolejny maintenance za dwa tygodnie”.

Dodatkowy krok po mitigacji: wyczyść page cache

To bardzo ważny detal. CloudLinux zwraca uwagę, że exploit może zmodyfikować legalne binarki w page cache podczas zdobywania roota, więc samo zablokowanie modułów po fakcie może być niewystarczające. Po wdrożeniu mitigacji zalecają zrzucenie page cache:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

To jest sensowne zwłaszcza wtedy, gdy istnieje ryzyko, że host mógł już zostać zaatakowany przed wprowadzeniem ochrony.

Co zrobić, aby uniknąć zagrożenia w przyszłości

Tu nie ma magii, ale są sensowne warstwy obrony.

1. Ogranicz lokalny dostęp

Dirty Frag to LPE. Bez lokalnego footholdu atakujący nie skorzysta z niego bezpośrednio. Red Hat wyraźnie podkreśla znaczenie ograniczania local access.

2. Nie dawaj shelli, runnerów i buildów „komu popadnie”

CI/CD, shared hosting, build farmy, debug kontenery i środowiska testowe to miejsca, gdzie tego typu luki są szczególnie groźne, bo ktoś już ma możliwość uruchomienia procesu lokalnie.

3. Utrzymuj SELinux/AppArmor i sensowne polityki

Red Hat wskazuje m.in. na SELinux enforcing i domyślne mechanizmy bezpieczeństwa jako element ograniczający ryzyko operacyjne. To nie leczy kernela, ale może utrudnić część scenariuszy.

4. Ogranicz user namespaces tam, gdzie nie są potrzebne

To nie zablokuje całego Dirty Frag w każdym środowisku, ale może ograniczyć jeden z wektorów. Write-up pokazuje, że właśnie dlatego exploit ma fallback na RxRPC.

5. Aktualizuj kernele szybciej przy krytycznych lukach lokalnych

Dirty Frag i wcześniejszy Copy Fail pokazują, że „to tylko lokalne” bywa zdradliwe. Na hostach współdzielonych lub z publicznymi workloadami lokalne LPE jest praktycznie incydentem krytycznym.

Sekcja praktyczna

Szybka checklista

1. Sprawdź dystrybucję i kernel

uname -r
cat /etc/os-release

2. Sprawdź obecność modułów

lsmod | egrep '^(esp4|esp6|rxrpc)\b'
modinfo esp4 2>/dev/null | head -n 5
modinfo esp6 2>/dev/null | head -n 5
modinfo rxrpc 2>/dev/null | head -n 5

3. Jeśli host nie używa IPsec, wdroż mitigację

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

4. Jeśli system mógł być już dotknięty, zrzuc page cache

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

5. Śledź advisory vendora i zainstaluj poprawiony kernel lub livepatch natychmiast po publikacji.

Garść ciekawostek

• Dirty Frag został publicznie ujawniony 7 maja 2026 r. po złamaniu embarga.
• Autor wskazuje, że exploit jest skuteczny bez race condition, więc nie przypomina kruchego „laboratoryjnego” PoC.
• To nie jest po prostu „Copy Fail 2”, ale nowy łańcuch błędów w innych podsystemach kernela.
• Na Ubuntu wariant RxRPC jest szczególnie istotny, bo rxrpc.ko bywa obecny domyślnie, a na części środowisk AppArmor ogranicza user namespaces, więc exploit przełącza się na drugi tor.
• Red Hat klasyfikuje temat jako Important, a nie Critical, ale to nie zmienia faktu, że przy realnym lokalnym dostępie skutkiem jest root.

Podsumowanie

Dirty Frag to bardzo poważna, świeżo ujawniona podatność LPE w jądrze Linuxa, która pozwala uzyskać roota na wielu głównych dystrybucjach. Na dziś nie ma jeszcze oficjalnego numeru CVE, ale istnieje publiczny exploit, techniczny opis, upstreamowy patch i vendorowe komunikaty ostrzegawcze.

Najważniejsze działanie tu i teraz jest proste: zminimalizować lokalną powierzchnię ataku, wdrożyć blokadę modułów esp4, esp6, rxrpc tam, gdzie to bezpieczne operacyjnie, a następnie natychmiast przejść na poprawiony kernel lub livepatch, gdy vendor go opublikuje. Jeśli host używa IPsec, nie wolno wdrażać tej mitigacji na ślepo, bo można sobie samemu odciąć tunel i potem zostać sam na sam z bardzo głupim wieczorem.

Źródła

1. Hyunwoo Kim, Dirty Frag: Universal Linux LPE, oss-security, 7/8 maja 2026.
2. LWN, Dirty Frag: a zero-day universal Linux LPE, 7 maja 2026.
3. Red Hat, RHSB-2026-003 Networking subsystem Privilege Escalation – Linux Kernel (Dirty Frag).
4. CloudLinux Blog, Dirty Frag [CVE Pending]: Mitigation and Kernel Update on CloudLinux.
5. CloudLinux KB, Vulnerability: Dirty Frag Local Privilege Escalation.
6. AlmaLinux, Dirty Frag vulnerability fix is ready for testing, 7 maja 2026.
7. GitHub / write-up techniczny, dirtyfrag/assets/write-up.md.

Autor: Redakcja youITcare · AI-Assisted
Artykuł opracowany przy wsparciu narzędzi sztucznej inteligencji, pod redakcyjnym nadzorem zespołu youITcare.