W świecie Linuksa pojawiło się poważne zagrożenie bezpieczeństwa: publicznie dostępny exploit pozwalający na lokalną eskalację uprawnień do roota. Co szczególnie niepokojące, kod wykorzystujący podatność ZDI-CAN-33367 został ujawniony, zanim luka otrzymała identyfikator CVE i zanim poprawka trafiła do stabilnego wydania jądra.
Jak informuje zespół Sysdig Threat Research Team, Trend Micro Zero Day Initiative (ZDI) ujawniło sześć problemów związanych z bezpieczeństwem Linuksa. Jednym z nich jest podatność w stosie sieciowym jądra, dla której opublikowano działający proof of concept (PoC). TuxCare potwierdziło możliwość uzyskania powłoki roota na kilku popularnych dystrybucjach.
Nie jest to jedynie teoretyczny problem. W przypadku podatności ZDI-CAN-33367 zwykły użytkownik lokalny może wykorzystać błąd w mechanizmie przetwarzania stron pamięci, aby doprowadzić do modyfikacji danych, które normalnie powinny pozostawać poza jego zasięgiem.
Sześć podatności Linuksa ujawnionych przez Zero Day Initiative
W październiku 2026 roku Trend Micro Zero Day Initiative przekazało informacje o sześciu podatnościach. Raporty zawierały szczegóły techniczne, w tym informacje umożliwiające odtworzenie części problemów.
W chwili publikacji analizy Sysdig żadna z sześciu luk nie miała przypisanego identyfikatora CVE. Nie odnotowano również potwierdzonych przypadków wykorzystania ich w rzeczywistych atakach.
Brak identyfikatora CVE nie oznacza jednak, że podatność jest niegroźna. W tym przypadku publicznie dostępny kod PoC pozwalał już na uzyskanie uprawnień roota.
Najważniejsze problemy z ujawnionej grupy obejmują:
- ZDI-CAN-33367 – lokalna eskalacja uprawnień w stosie sieciowym Linuksa, związana z funkcją
skb_zerocopy()i mechanizmem ochrony przed Dirty Frag. - ZDI-CAN-33774 – podatność w serwerze SMB
ksmbd, umożliwiająca zdalny wyciek pamięci jądra i potencjalne doprowadzenie do awarii systemu bez wcześniejszego uwierzytelnienia. - ZDI-CAN-33549 – problem w obsłudze SMB Direct, związany z przepełnieniem sterty w określonych warunkach.
- ZDI-CAN-34068 – lokalna podatność w sterowniku
vmwgfx, wykorzystywanym w maszynach wirtualnych VMware. - ZDI-CAN-34076 – problem związany z obsługą NVMe Target (
nvmet) i ujawnianiem informacji. - ZDI-CAN-32005 – przepełnienie stosu w serwerze DNS proxy menedżera sieci ConnMan; jest to problem przestrzeni użytkownika, a nie bezpośrednio jądra.
Dwie podatności dotyczące ksmbd otrzymały ocenę CVSS 9.0. W przypadku ZDI-CAN-33367 publikowane oceny różnią się między raportami: artykuł Sysdig podaje CVSS 7.8, natomiast część wstępnych doniesień wskazywała 7.5. Niezależnie od różnicy w punktacji, najważniejszym czynnikiem jest obecność publicznego exploita oraz możliwość przejęcia uprawnień roota.
ZDI-CAN-33367 – eskalacja uprawnień przez stos sieciowy
Najbardziej niepokojącą podatnością z całej grupy jest ZDI-CAN-33367. Dotyczy ona funkcji skb_zerocopy() w jądrze Linuksa, wykorzystywanej do przenoszenia danych pomiędzy strukturami buforów sieciowych bez konieczności ich pełnego kopiowania.
Aby zrozumieć problem, należy przyjrzeć się mechanizmowi Dirty Frag.
Czym był Dirty Frag?
Dirty Frag to klasa podatności związana z możliwością modyfikowania zawartości pamięci podręcznej stron plików (page cache) przez nieuprawnionego użytkownika.
Page cache jest mechanizmem jądra, który przechowuje w pamięci RAM zawartość plików. Dzięki temu kolejne operacje odczytu mogą być znacznie szybsze niż pobieranie danych bezpośrednio z nośnika.
W normalnych warunkach użytkownik, który ma jedynie prawo odczytu pliku, nie powinien być w stanie zmodyfikować jego zawartości.
Problem Dirty Frag dotyczył ścieżki przetwarzania danych IPsec ESP. W określonych warunkach jądro mogło odszyfrowywać dane bezpośrednio w stronach pamięci współdzielonych z page cache. W efekcie dane zapisane w pamięci podręcznej mogły zostać zmienione, mimo że użytkownik nie miał uprawnień do zapisu w pliku.
Takie zachowanie mogło prowadzić do modyfikacji plików o podwyższonych uprawnieniach, a w konsekwencji do przejęcia systemu.
Jak działa luka ZDI-CAN-33367?
Poprawka Dirty Frag wprowadziła znacznik informujący, że określone strony pamięci są współdzielone i nie powinny być modyfikowane bezpośrednio przez mechanizm deszyfrowania.
Odpowiedni kod IPsec został zmodyfikowany tak, aby w przypadku wykrycia tego znacznika wykonać operację na kopii danych.
Problem pojawił się w funkcji skb_zerocopy().
Funkcja ta może przenosić strony pamięci do nowego bufora sieciowego. W podatnej ścieżce nie przenosiła jednak odpowiedniego znacznika ochronnego.
W uproszczeniu wygląda to następująco:
- Użytkownik inicjuje operację, która prowadzi do utworzenia współdzielonych stron pamięci.
- Dane trafiają do struktur wykorzystywanych przez stos sieciowy.
- Funkcja
skb_zerocopy()przenosi strony do nowego bufora. - Podczas przenoszenia zostaje utracony znacznik ochronny.
- Kod IPsec nie rozpoznaje, że strony powinny być traktowane jako współdzielone.
- Deszyfrowanie może zmodyfikować zawartość page cache.
W ten sposób luka w jednej funkcji sieciowej osłabia ochronę wprowadzoną przez wcześniejszą poprawkę.
To ważny przykład problemu charakterystycznego dla dużych systemów operacyjnych: naprawienie podatności nie wystarczy, jeśli wszystkie ścieżki przetwarzania danych nie respektują wprowadzonych zabezpieczeń.
Dlaczego publiczny exploit jest szczególnie niebezpieczny?
Podatność ZDI-CAN-33367 ma charakter lokalnej eskalacji uprawnień (Local Privilege Escalation, LPE).
Oznacza to, że atakujący musi już mieć możliwość uruchamiania kodu na maszynie. Nie jest to typowy scenariusz, w którym samo wysłanie pakietu sieciowego do serwera pozwala na przejęcie systemu.
Jednak w praktyce lokalny dostęp może zostać uzyskany na wiele sposobów:
- poprzez przejęcie konta użytkownika,
- wykorzystanie podatności w aplikacji internetowej,
- uruchomienie złośliwego programu,
- kompromitację konta w środowisku wieloużytkownikowym,
- uzyskanie dostępu do kontenera, który nie jest odpowiednio odizolowany.
Po uzyskaniu dostępu do zwykłego konta użytkownika atakujący może próbować wykorzystać podatność, aby przejść do uprawnień roota.
TuxCare potwierdziło reprodukcję exploita na następujących systemach:
| Dystrybucja | Wersje |
|---|---|
| AlmaLinux | 8, 9 i 10 |
| Debian | 12 i 13 |
| Ubuntu | 24.04 i 26.04 |
Testy wykazały, że podatność może być wykorzystana nawet na systemach, na których wcześniej zainstalowano poprawkę Dirty Frag.
Warto podkreślić, że publiczny PoC nie jest równoznaczny z potwierdzonym wykorzystaniem podatności w rzeczywistych kampaniach cyberprzestępczych. Sysdig nie raportował takich incydentów w momencie publikacji swojej analizy.
Dwie poważne podatności w ksmbd
Drugim istotnym elementem ujawnionej grupy są problemy w ksmbd, czyli serwerze SMB działającym bezpośrednio w jądrze Linuksa.
SMB (Server Message Block) jest protokołem wykorzystywanym do udostępniania plików i zasobów w sieci. Jest powszechnie stosowany w środowiskach Windows oraz w systemach Linux.
W Linuksie można spotkać dwa różne rozwiązania serwera SMB:
- Samba – serwer działający w przestrzeni użytkownika.
- ksmbd – implementacja serwera SMB z istotną częścią logiki działającą w jądrze.
To rozróżnienie ma kluczowe znaczenie dla oceny ryzyka. Podatności opisane przez ZDI dotyczą ksmbd, a nie automatycznie każdej instalacji Samby.
ZDI-CAN-33774 – wyścig w obsłudze SMB
Pierwsza z luk dotyczy mechanizmu rozdzielania żądań SMB1 i SMB2.
W określonych warunkach współbieżność obsługi żądań może doprowadzić do sytuacji, w której kod przetwarzający żądanie SMB2 operuje na danych pochodzących z krótszego pakietu SMB1.
Może to skutkować odczytem poza granicami bufora.
Podatność jest szczególnie niebezpieczna, ponieważ może zostać wykorzystana przed uwierzytelnieniem. Publiczny PoC demonstrował możliwość ujawnienia fragmentu pamięci sterty jądra oraz doprowadzenia do awarii systemu.
ZDI-CAN-33549 – przepełnienie sterty w SMB Direct
Druga podatność związana jest z obsługą transportu SMB Direct wykorzystującego RDMA (Remote Direct Memory Access).
Problem wynika z błędu arytmetycznego – niedomiaru wartości całkowitej (integer underflow) – który może prowadzić do nieprawidłowego obliczenia rozmiaru bufora.
W określonych warunkach atakujący może doprowadzić do przepełnienia pamięci sterty. Wymagania dotyczące wykorzystania tej podatności są jednak bardziej ograniczone. Host musi m.in. obsługiwać RDMA, a scenariusz ataku wymaga odpowiedniej konfiguracji SMB Direct i zapisywalnego udziału.
Obie podatności otrzymały ocenę CVSS 9.0.
Dla administratorów oznacza to, że serwer wykorzystujący ksmbd do udostępniania plików powinien zostać potraktowany jako potencjalnie narażony. Systemy korzystające wyłącznie z Samby nie są automatycznie objęte tymi konkretnymi problemami.
Jak sprawdzić, czy system korzysta z ksmbd?
Administrator może rozpocząć od sprawdzenia, czy moduł jądra jest załadowany:
lsmod | grep ksmbdMożna również sprawdzić, czy działa proces zarządzający serwerem:
ps aux | grep ksmbdKolejnym krokiem jest kontrola portu SMB:
ss -ltnp | grep ':445'Sam port 445 nie przesądza o używaniu ksmbd, ponieważ może być wykorzystywany również przez Sambę. Warto sprawdzić procesy i moduły, aby prawidłowo określić ekspozycję systemu.
Jak ograniczyć ryzyko wykorzystania podatności?
Sysdig podkreśla, że administratorzy powinni oceniać ryzyko na podstawie rzeczywistego wykorzystania podatnego komponentu, a nie wyłącznie na podstawie wartości CVSS.
W praktyce oznacza to, że serwer z aktywnym ksmbd, wystawiony do niezaufanej sieci, może wymagać pilniejszej reakcji niż komputer, na którym dana funkcja nie jest wykorzystywana.
1. Aktualizacja jądra Linuksa
Najważniejszym działaniem jest instalacja poprawki udostępnionej przez producenta dystrybucji.
Nie należy zakładać, że każda wersja jądra zawierająca poprawkę Dirty Frag jest już zabezpieczona przed ZDI-CAN-33367.
W chwili publikacji analizy Sysdig poprawka dla skb_zerocopy() była dostępna w postaci zgłoszonego patcha, ale nie znajdowała się jeszcze w głównym drzewie jądra. Sytuacja dystrybucji zmieniała się jednak szybko. Według aktualizacji Sysdig z 28 października 2026 r. poprawione jądro dla AlmaLinux 9 zostało już udostępnione, a poprawki dla kolejnych wersji były przygotowywane. KernelCare opublikował również poprawki bez konieczności restartu dla EL10 i EL9.
Przed aktualizacją warto sprawdzić dostępne pakiety:
Debian / Ubuntu:
sudo apt update
apt list --upgradableAlmaLinux / RHEL:
sudo dnf check-updatePo aktualizacji jądra należy sprawdzić jego wersję:
uname -rSama aktualizacja pakietu nie zawsze oznacza, że poprawione jądro zostało już uruchomione. W wielu przypadkach wymagany będzie restart systemu.
2. Ograniczenie nieuprzywilejowanych przestrzeni nazw użytkownika
Publiczny exploit wykorzystuje możliwość tworzenia nieuprzywilejowanych przestrzeni nazw użytkownika (user namespaces).
W zależności od dystrybucji administrator może rozważyć ograniczenie tej funkcji.
Na Debianie i Ubuntu można sprawdzić ustawienie:
sysctl kernel.unprivileged_userns_cloneNa systemach korzystających z ogólnego parametru jądra:
sysctl user.max_user_namespacesW środowiskach, które nie wymagają user namespaces, możliwe jest czasowe ograniczenie ich dostępności. Przykładowo:
sudo sysctl -w user.max_user_namespaces=0Na Debianie, jeśli dostępny jest odpowiedni parametr:
sudo sysctl -w kernel.unprivileged_userns_clone=0Uwaga: wyłączenie user namespaces może negatywnie wpłynąć na rootless kontenery, piaskownice przeglądarek internetowych oraz narzędzia deweloperskie. Nie powinno być stosowane bez sprawdzenia zależności w środowisku produkcyjnym.
Jest to środek ograniczający możliwość wykorzystania publicznego PoC, a nie zamiennik poprawki jądra.
3. Ograniczenie ładowania modułów sieciowych
Exploit wykorzystuje określone komponenty stosu sieciowego, w tym mechanizmy związane z nlmon i akcją act_pedit.
W środowiskach, które nie korzystają z tych funkcji, administrator może rozważyć ograniczenie możliwości ładowania odpowiednich modułów.
Przykładowo można sprawdzić ich obecność:
lsmod | grep -E 'nlmon|act_pedit'Należy jednak pamiętać, że blokowanie modułów może wpłynąć na diagnostykę sieci, konfigurację ruchu oraz inne funkcje systemu. Takie działanie powinno być poprzedzone analizą używanych usług.
4. Wyłączenie ksmbd, jeśli nie jest potrzebny
Jeżeli serwer nie korzysta z ksmbd, jego wyłączenie może znacząco zmniejszyć powierzchnię ataku.
W pierwszej kolejności należy upewnić się, że usługa nie jest wykorzystywana przez użytkowników ani aplikacje.
Jeżeli moduł jest załadowany, administrator może rozważyć jego usunięcie:
sudo modprobe -r ksmbdPolecenie może zakończyć się błędem, jeśli moduł jest aktywnie używany. Nie należy wymuszać jego usunięcia bez sprawdzenia zależności.
Aby ograniczyć automatyczne ładowanie modułu, można utworzyć plik:
sudo nano /etc/modprobe.d/disable-ksmbd.confi umieścić w nim:
blacklist ksmbdW niektórych konfiguracjach może być potrzebna dodatkowa reguła install, a skuteczność blokady należy zweryfikować po restarcie. Nie należy stosować jej na serwerach, które rzeczywiście korzystają z ksmbd.
5. Ograniczenie dostępu do SMB
Jeśli ksmbd musi pozostać aktywny, warto ograniczyć dostęp do portu TCP 445.
Najlepiej zezwolić na połączenia wyłącznie z zaufanych sieci, takich jak segment LAN przeznaczony dla serwerów plików.
Nie należy wystawiać usług SMB bezpośrednio do Internetu, jeśli nie jest to absolutnie konieczne.
W przypadku SMB Direct warto również rozważyć wyłączenie obsługi RDMA, jeśli środowisko nie korzysta z tej funkcji.
Wykrywanie próby wykorzystania exploita
Sysdig zwraca uwagę, że ZDI-CAN-33367 może być stosunkowo łatwa do wykrycia za pomocą monitorowania zachowania procesów.
Publiczny PoC wykonuje charakterystyczną sekwencję operacji systemowych:
- tworzenie nowych przestrzeni nazw użytkownika i sieci,
- konfigurację parametrów sysctl,
- uruchomienie interfejsu
nlmon, - instalację stanu XFRM przez netlink,
- konfigurację reguł nftables wykorzystujących NFQUEUE,
- zastosowanie akcji
tctypupedit, - wykorzystanie
splice()w komunikacji z lokalnym gniazdem.
Takie połączenie działań wykonywanych przez jeden nieuprzywilejowany proces jest nietypowe dla standardowych aplikacji.
Administratorzy mogą wykorzystać narzędzia monitorujące zachowanie procesów, systemy EDR oraz mechanizmy audytu wywołań systemowych do identyfikowania podobnych sekwencji.
W środowiskach Kubernetes warto również zadbać o właściwe profile seccomp. Sysdig wskazuje, że profile RuntimeDefault mogą ograniczyć możliwość wykonywania niektórych operacji potrzebnych do rozpoczęcia exploita.
Nie jest to jednak pełna ochrona przed wszystkimi wariantami podatności.
Dlaczego warto patrzeć na rzeczywistą ekspozycję, a nie tylko CVSS?
Ocena CVSS jest użytecznym narzędziem do klasyfikowania podatności, ale nie zawsze pozwala prawidłowo ustalić kolejność działań administratora.
W omawianej grupie problemów:
- ZDI-CAN-33367 ma niższą ocenę niż luki w
ksmbd, ale posiada publiczny exploit pozwalający na uzyskanie roota. - Podatności
ksmbdsą ocenione na CVSS 9.0, ale dotyczą wyłącznie hostów korzystających z tego serwera. - Problem w
vmwgfxma znaczenie przede wszystkim w maszynach wirtualnych VMware. - Luka w ConnMan dotyczy przestrzeni użytkownika i wymaga odrębnej analizy.
Dlatego właściwa kolejność działań powinna uwzględniać:
- Czy podatny komponent jest aktywny?
- Czy jest dostępny dla niezaufanych użytkowników lub sieci?
- Czy istnieje działający exploit?
- Czy system ma już poprawkę?
- Jakie skutki może mieć wyłączenie danego komponentu?
Takie podejście pozwala uniknąć sytuacji, w której administrator skupia się wyłącznie na najwyższej liczbie CVSS, pomijając podatność o bardziej bezpośrednim wpływie na własną infrastrukturę.
Podsumowanie
ZDI-CAN-33367 pokazuje, jak niebezpieczne mogą być luki w mechanizmach ochronnych jądra Linuksa. Publiczny exploit umożliwiający lokalną eskalację uprawnień do roota został ujawniony przed przypisaniem identyfikatora CVE i przed pełnym wdrożeniem poprawki.
Problem jest szczególnie interesujący z technicznego punktu widzenia, ponieważ stanowi kolejną lukę w ochronie związanej z Dirty Frag. Funkcja skb_zerocopy() nie przenosiła znacznika zabezpieczającego współdzielone strony pamięci, co pozwalało na ponowne otwarcie ścieżki prowadzącej do modyfikacji page cache.
Administratorzy powinni przede wszystkim:
- sprawdzić dostępność aktualizacji jądra,
- zweryfikować, czy system korzysta z
ksmbd, - wyłączyć niepotrzebne usługi SMB w jądrze,
- ograniczyć dostęp do portu 445,
- rozważyć ograniczenie nieuprzywilejowanych user namespaces,
- monitorować nietypowe zachowanie procesów.
Najważniejszy wniosek jest prosty: brak CVE lub brak oficjalnej poprawki nie oznacza braku zagrożenia. W przypadku Linuksa publiczny kod PoC może sprawić, że podatność stanie się realnym problemem dla administratorów jeszcze zanim zakończy się standardowy proces publikowania i dystrybucji aktualizacji bezpieczeństwa.
