Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
OVSwrap to nowo ujawniona podatność typu local privilege escalation w jądrze Linux, powiązana z kernelowym datapath Open vSwitch. Błąd prowadzi do korupcji pamięci podczas przetwarzania akcji sieciowych i w określonych warunkach może umożliwić lokalnemu użytkownikowi przejęcie uprawnień roota.
Problem ma szczególne znaczenie dla środowisk wieloużytkownikowych, serwerowych, kontenerowych i chmurowych, gdzie przejęcie zwykłego konta może stać się punktem wyjścia do pełnej kompromitacji hosta.
W skrócie
Podatność została oznaczona jako CVE-2026-64531 i oceniona na 7.8 w skali CVSS. Dotyczy ona datapath Open vSwitch działającego w jądrze, a nie wyłącznie komponentów użytkownika odpowiedzialnych za zarządzanie przełączaniem.
Istotne jest to, że atakujący nie musi mieć aktywnego mostu OVS ani uruchomionego demona zarządzającego, aby wejść na podatną ścieżkę wykonania. Ryzyko dotyczy głównie systemów z dostępnym modułem Open vSwitch oraz włączoną obsługą nieuprzywilejowanych przestrzeni nazw użytkownika. Dodatkowym czynnikiem podnoszącym zagrożenie jest publicznie dostępny kod PoC wraz z rekordami dla wielu konkretnych kompilacji jądra.
Kontekst / historia
OVSwrap został publicznie ujawniony pod koniec lipca 2026 roku po wcześniejszym zgłoszeniu do maintainerów jądra Linux oraz opiekunów Open vSwitch. Sam problem logiczny istniał od dłuższego czasu, jednak przez lata był częściowo maskowany przez wcześniejsze ograniczenia rozmiaru generowanego strumienia akcji.
Sytuacja zmieniła się po modyfikacji wprowadzonej w marcu 2025 roku, która usunęła limit 32 KiB ze względów związanych z niezawodnością i kompatybilnością. Zmiana ta nie stworzyła podatności od podstaw, ale odsłoniła starszy błąd związany z niebezpieczną obsługą długości atrybutów Netlink.
Choć poprawki trafiły do stabilnych gałęzi jądra przed szerokim nagłośnieniem sprawy, rzeczywisty poziom bezpieczeństwa nadal zależy od szybkości dystrybucji łatek przez dostawców systemów operacyjnych oraz od stosowanych przez nich backportów.
Analiza techniczna
Źródłem problemu jest sposób, w jaki Open vSwitch zapisuje wygenerowane akcje przepływu jako atrybuty Netlink. Pole nla_len ma szerokość 16 bitów, co oznacza ograniczenie długości pojedynczego zagnieżdżonego atrybutu do 65 535 bajtów.
Eksploatacja polega na doprowadzeniu do sytuacji, w której wygenerowana struktura akcji przekracza tę granicę. W efekcie dochodzi do przepełnienia typu i obcięcia długości, a dalsze fragmenty kodu ufają błędnej wartości i kontynuują parsowanie wewnątrz danych kontrolowanych przez atakującego.
Publicznie opisany scenariusz zakłada użycie akcji CLONE zawierającej dużą liczbę pod-akcji conntrack. W określonych warunkach jądro rozwija taką strukturę do rozmiaru przekraczającego limit pola długości, co otwiera drogę do korupcji pamięci jądra bez konieczności zaawansowanego przygotowania sterty.
Łańcuch eksploatacji wykorzystuje trzy kluczowe prymitywy:
- wyciek wskaźnika jądra,
- arbitralny odczyt pamięci jądra,
- ukierunkowaną modyfikację wybranych wartości.
W praktyce pozwala to odnaleźć struktury poświadczeń procesu i doprowadzić do uzyskania uprawnień roota. Opisany PoC ma charakter destrukcyjny i pozostawia po sobie ślady, w tym zmiany w konfiguracji sudo oraz artefakty w stanie procesów i OVS.
Ważnym aspektem jest również możliwość automatycznego załadowania modułu Open vSwitch podczas rozwiązywania nazwy rodziny Generic Netlink. Oznacza to, że brak aktywnego modułu na liście załadowanych komponentów nie zawsze oznacza brak podatności.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją OVSwrap jest lokalna eskalacja uprawnień do poziomu root, czyli przejście od zwykłego użytkownika do pełnej kontroli nad systemem. W środowiskach współdzielonych oznacza to realne ryzyko przejęcia całego hosta po kompromitacji pojedynczego konta, aplikacji lub usługi.
Ryzyko wzrasta z uwagi na dostępność publicznego PoC oraz gotowych rekordów dla licznych buildów jądra x86-64. Obniża to próg wejścia dla atakujących i zwiększa prawdopodobieństwo szybkiego wdrożenia exploita w praktycznych kampaniach.
Wyłączenie nieuprzywilejowanych user namespaces może ograniczyć najprostszy scenariusz ataku, ale nie eliminuje wszystkich ścieżek. Procesy lub kontenery posiadające CAP_NET_ADMIN we własnej przestrzeni nazw sieciowej nadal mogą potencjalnie dotrzeć do podatnej funkcjonalności.
Rekomendacje
Najważniejszym działaniem obronnym jest możliwie szybka instalacja zaktualizowanego jądra dostarczonego przez producenta dystrybucji. W ocenie podatności należy opierać się przede wszystkim na biuletynach i trackerach dostawcy, a nie jedynie na numerach wersji upstream.
Jeżeli Open vSwitch nie jest niezbędny operacyjnie, warto tymczasowo zablokować możliwość ładowania modułu jądra i usunąć go z pamięci, jeśli został już załadowany. W niektórych przypadkach może to wymagać restartu systemu.
Dodatkowo zalecane jest:
- wyłączenie nieuprzywilejowanych przestrzeni nazw użytkownika tam, gdzie jest to możliwe,
- przegląd hostów korzystających z Open vSwitch w środowiskach wirtualizacyjnych, kontenerowych i chmurowych,
- weryfikacja działania mechanizmów takich jak AppArmor, SELinux i polityk ograniczających tworzenie przestrzeni nazw,
- monitorowanie prób użycia
unshare, nietypowych operacji Generic Netlink oraz anomalii związanych z OVS i conntrack, - kontrolę zmian w plikach sudoers i innych artefaktach mogących wskazywać na lokalną eskalację uprawnień,
- priorytetyzację aktualizacji na hostach współdzielonych i uruchamiających nieufne workloady.
Zespoły bezpieczeństwa powinny także sprawdzić, czy ich środowiska wykorzystują funkcje conntrack oraz powiązane helpery, ponieważ publiczny łańcuch eksploatacji zakłada obecność określonych komponentów.
Podsumowanie
OVSwrap pokazuje, że starsze, pozornie uśpione błędy w kodzie jądra mogą stać się bardzo groźne po zmianach poprawiających niezawodność i kompatybilność. CVE-2026-64531 umożliwia lokalną eskalację uprawnień do roota przez kernelowy datapath Open vSwitch, a dostępność publicznego PoC zwiększa presję na szybkie działania naprawcze.
Organizacje powinny potraktować tę podatność priorytetowo, zwłaszcza jeśli utrzymują środowiska wieloużytkownikowe, platformy kontenerowe lub infrastrukturę opartą na Open vSwitch.
Źródła
- The Hacker News — New OVSwrap Linux Kernel Flaw Lets Local Users Gain Root via Open vSwitch — https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
- Technical write-up by Asim Manizada — https://heyitsas.im/posts/2026-07-28-ovswrap/
- Linux kernel upstream fix / stable references — https://github.com/torvalds/linux
- Open vSwitch related upstream changes discussion — https://github.com/openvswitch/ovs
- CloudLinux advisory — https://blog.cloudlinux.com/