Wnioski z operacji naprawczej przeprowadzonej w ciągu tygodnia na całym naszym parku KVM, zgodnie ze strategią łatania, której głównym celem było zminimalizowanie wpływu na usługi naszych klientów.

Luka w podsystemie wirtualizacji

We wtorek 7 lipca, wczesnym popołudniem, otrzymano alert bezpieczeństwa dotyczący CVE-2026-53359, luki typu use-after-free wpływającej na podsystem shadow-paging KVM x86 w jądrze Linux. Luka, znana od kilku lat, została upubliczniona 6 lipca; blogi innych dostawców chmurowych pojawiły się już 7 lipca.KVM stanowi silnik wirtualizacji, na którym opiera się ogromna większość instancji hostowanych w OVHcloud. Mechanizm jest następujący: gdy występuje zewnętrzna modyfikacja

Page Directory Entry (PDE), wpis RMAP może zachować odwołanie do już zwolnionej strony pamięci. Jądro następnie dereferencjuje tę przestarzałą stronę, co może prowadzić do awarii hiperwizora lub, w najgorszych scenariuszach, do podniesienia uprawnień po stronie hosta. Exploit jest powtarzalny: test wewnętrzny na niezałatanym hoście powoduje awarię w około dwie minuty.Problem dotyczy wszystkich jąder Linux x86 sprzed

commit z poprawką, bez rozróżnienia na dystrybucje. Oficjalna poprawka została przeniesiona (backport) do naszych produkcyjnych jąder Debian.Należy wziąć pod uwagę 3 główne ryzyka:

Klient VPS wykorzystuje exploit do zawieszenia hosta, na którym działa jego maszyna wirtualna: awaria i niekontrolowany restart setek maszyn wirtualnych klientów.

• Identyczny scenariusz w przypadku instancji Public Cloud, wpływ jest podobny, ale liczba maszyn wirtualnych na hosta jest mniejsza, a maszyny wirtualne są potężniejsze i wykorzystywane do bardziej wrażliwych systemów (bazy danych, menedżery kolejek, load balancery itp.). Systemy te są często używane w złożonych architekturach aplikacyjnych z wieloma zależnościami.
• Prawdopodobieństwo nadchodzącej publikacji exploita przejmującego kontrolę nad hostem, co natychmiast podniosłoby poziom ryzyka do nieakceptowalnego ze względu na wpływ na poufność danych klientów i integralność infrastruktury.
• Dla OVHcloud zakres obejmuje dziesiątki tysięcy serwerów hostujących hiperwizory, obsługujących

około milion maszyn wirtualnych. Pytanie nie brzmi zatem, czy należy stosować poprawki, ale jak przeprowadzić tę operację na taką skalę, wiedząc, że zerowy wpływ na klienta jest nieosiągalny. mener cette opération à une telle échelle, en sachant qu’un impact client nul n’est pas atteignable.

Opcje dostępne w celu ograniczenia ryzyka

1. Czekanie na oficjalne załatane jądra

Ta opcja uzależniała nas od harmonogramu podmiotów zewnętrznych, co pozostawiało nas w stanie ryzyka przez nieokreślony czas. Szybko ją odrzuciliśmy ze względu na ryzyko.

2. Live patch

Zastosowanie live patcha wymaga zezwolenia na tego typu operację w konfiguracji jądra, co z założenia pozwala na modyfikację jego zachowania w locie, prowadząc tym samym do obniżenia poziomu jego zabezpieczeń i ograniczając możliwości wykrywania w przypadku jego kompromitacji. Ponadto live patch jest procedurą z natury wrażliwą, która może prowadzić do niestabilnego stanu w skali całej infrastruktury. Jest to opcja, która pozwala zyskać na czasie w oczekiwaniu na trwałe rozwiązanie. Zdecydowaliśmy się nie iść na ten kompromis, który bardzo znacząco zwiększyłby ryzyko w przypadku publikacji exploita umożliwiającego przejęcie kontroli nad hostem.

3. Ochrona przed atakami w OVH poprzez wyłączenie zagnieżdżonej wirtualizacji

Wyłączenie zagnieżdżonej wirtualizacji na hostach pozwala unieszkodliwić exploit. Nie mamy wglądu w to, czy nasi klienci korzystają z tej funkcjonalności, więc niemożliwe jest określenie wpływu na usługi klientów, a funkcjonalność ta jest niezbędna do zachowania możliwości migracji na żywo instancji z jednego hosta fizycznego na drugi. Szybko odrzucamy ten kierunek.

4. Migracja na żywo

Zorganizowanie migracji na żywo maszyn wirtualnych z podatnych hostów na puste hosty, które zostały w międzyczasie załatane. Opcja ta jest bardzo satysfakcjonująca pod względem ciągłości usług, ponieważ migracja odbywa się bez wpływu na maszyny wirtualne, z wyjątkiem obniżonej wydajności podczas migracji. Opcja ta zajmuje dużo czasu ze względu na kopiowanie maszyn wirtualnych z hosta na hosta; nie jest ona realistycznie możliwa do zastosowania w skali całej infrastruktury, biorąc pod uwagę chęć ochrony naszych klientów w ciągu kilku dni, a nie kilku miesięcy. Decydujemy się zachować tę opcję tylko dla niektórych krytycznych maszyn wirtualnych, ponieważ każda migracja na żywo powoduje znaczne opóźnienie w realizacji zadań wsadowych.

5. Backport poprawki na nasze jądra i restart wszystkich hostów

Ostatecznie to właśnie ta opcja zostanie wybrana i szczegółowo opisana w dalszej części artykułu.

Wtorek po południu: uruchomienie i organizacja komórki kryzysowej

Z chwilą potwierdzenia podatności priorytetem staje się zbudowanie ustrukturyzowanej i skoordynowanej odpowiedzi; analitycy odpowiedzialni za tę pierwszą analizę bardzo szybko rozumieją wyzwania nadchodzących dni. Informacja jest rozpowszechniana wewnętrznie na początku popołudnia. Otwarto kilka przestrzeni koordynacyjnych: jedną dla koordynacji technicznej, jedną dla koordynacji kryzysowej, jedną dla operacji w USA oraz jedną dla komunikacji z klientami i wsparcia. W tym samym czasie zespoły Kernel przygotowują i wykonują backport poprawki; pierwsze załatane jądro zostaje dostarczone wieczorem.

Testy walidacyjne są przeprowadzane w środowisku testowym wieczorem. Poprawka została potwierdzona, exploit nie powoduje już awarii załatanych hypervisorów, a testy QA przechodzą pomyślnie z załatanym jądrem.

Zespół kryzysowy przekształca się w zespół monitorujący wdrożenie, a następnie jest kierowany przez NOC (Network Operations Center), który przejmuje rolę koordynatora operacyjnego: monitorowanie ogólnego postępu, arbitraż priorytetów między regionami i usługami, utrzymanie całościowego obrazu sytuacji. Wykonanie zadań spoczywa na ekspertach Public Cloud i VPS, którzy przeprowadzają restarty, live-migrate oraz zarządzają ograniczeniami anty-afinitetu. Rozdzielenie koordynacji od wykonania jest celowe: NOC koordynuje, zespoły operacyjne działają i przekazują metryki oraz zdarzenia techniczne niezbędne do koordynacji.

Synchronizacja z Działem Wsparcia Klienta (status postępu w czasie rzeczywistym w celu udzielania odpowiedzi klientom, których dotyczy problem) oraz zespołami ds. bezpieczeństwa (monitorowanie podatności, walidacja zakresu i kryteriów zakończenia operacji) jest zapewniona w sposób ciągły.

Ponieważ operacja odbywa się w trybie follow the sun, zespół pracuje w systemie 24/7 z rotacją według stref geograficznych. Każdego dnia odbywają się trzy punkty synchronizacji, obejmujące przejścia między strefami. Gromadzą one NOC, ekspertów operacyjnych, Dział Wsparcia i zespół ds. bezpieczeństwa w celu: udostępnienia statusu postępu w poszczególnych regionach, przekazania zadań między strefami (co zadziałało, korekty procedur na podstawie informacji zwrotnych z terenu) oraz ustalenia priorytetów na kolejną sekwencję.

Pełny zespół obejmuje, w rotacji 24/7: zespoły Kernel & Virtualization (analiza poprawki, backport, walidacja), VPS i Public Cloud (wdrożenie), NOC (kierowanie), Run & SRE (orkiestracja, anty-afinitet, live migration), Datacenter Operations (interwencje sprzętowe), Dział Wsparcia Klienta (zapytania klientów), Bezpieczeństwo (monitorowanie, zakres, zakończenie operacji) oraz Komunikacja (przejrzystość, ukierunkowane powiadomienia).

Wyznaczony cel jest jasny: spatchować i zrestartować odpowiednie hosty w jak najkrótszym czasie, aby zmniejszyć okno podatności, minimalizując wpływ na usługi. Główne ograniczenie wynika ze skali: dziesiątki tysięcy maszyn do przetworzenia na wszystkich kontynentach, przy czym obsługa każdego przypadku z osobna jest przy tej skali fizycznie niemożliwa.

Głównym ryzykiem na tym etapie jest wykorzystanie podatności, prowadzące do awarii niezałatanych hostów. Zespół kryzysowy decyduje o zastosowaniu poprawki globalnie przed fazą restartu. W przypadku wykorzystania luki, awaria hosta spowoduje jego restart i automatyczne uwzględnienie poprawki. Ponadto istnieje ryzyko, że CVE zostanie wykorzystane do złośliwego przejęcia kontroli nad hostem. Żaden kod exploita nie jest publicznie dostępny, ale wiemy, że to tylko kwestia czasu, zanim badaczowi uda się wykorzystać tę lukę do przejęcia kontroli nad hostem. Ponieważ ten scenariusz jest katastrofalny, wiemy, że liczy się każda minuta.

Świadoma decyzja: jednostronne zastosowanie poprawki o kontrolowanym wpływie

Komitet Wykonawczy zatwierdza Go/No-Go wieczorem: pierwszy region zostanie obsłużony następnego dnia rano. Dla tej liczby maszyn nie istnieje żaden scenariusz bez wpływu. Negocjowanie okna serwisowego z każdym klientem, weryfikacja każdej zależności, orkiestracja każdego restartu na miarę — to wszystko etapy materialnie niekompatybilne z akceptowalnym terminem w obliczu ryzyka bezpieczeństwa.

Zespół kryzysowy podejmuje zatem świadomą decyzję: jednostronne zastosowanie poprawki o kontrolowanym wpływie, wdrażane bez czekania na indywidualną zgodę każdego klienta, ze świadomością, że niektóre usługi ulegną przerwaniu. Rozumowanie opiera się na trzech punktach:

• brak zastosowania poprawki naraża cały park maszynowy na lukę o wysokim stopniu zagrożenia;
• traktowanie każdego przypadku z osobna wydłużyłoby czas realizacji i pozostawiłoby większość hostów podatnymi na ataki przez wiele tygodni;
• szybkie i globalne działanie chroni największą liczbę osób, nawet kosztem tymczasowego wpływu na mniejszość.

Priorytetem nie jest już zatem unikanie wpływu, lecz jego minimalizacja, rozproszenie i uczynienie przewidywalnym. To właśnie ta linia wyznacza strukturę całej operacji: follow the sun, priorytetyzacja regionów i planowanie anty-afinityczne.

Środa, 8 lipca: start z Sydney

Wybór Sydney do przetestowania wdrożenia jest trywialny: liczba hostów jest ograniczona, a okno wdrożeniowe w lokalnych godzinach nocnych (HNO) odpowiada godzinom pracy zespołów w Europie. Rozpoczęcie od najbardziej wysuniętego na wschód regionu pozwala na:

• działanie w najmniej obciążonej strefie;
• zatwierdzenia procedury w warunkach rzeczywistych, na mniejszą skalę, przed wdrożeniem do produkcji;
• zebrania pierwszych opinii przed uruchomieniem regionów europejskich i północnoamerykańskich.

Pierwsze fale patch + reboot są stosowane na hostach VPS w Australii. Region SYD2 został zakończony wczesnym popołudniem (czasu paryskiego), bez incydentów. Procedury są dostosowywane na podstawie opinii z terenu.

Gdy tylko procedura zostanie ustabilizowana, uruchamiany jest follow the sun: każdy region przejmuje zadania po kolei, w swoim lokalnym poranku, przekazując kontekst następnemu. Pierwsza fala europejska (RBX, GRA6, WAW, DE, SBG, MIL, UK) została uruchomiona tego samego wieczoru, o 18:30 czasu paryskiego.

Dwa zakresy, dwie ekspozycje: Najpierw VPS, potem Public Cloud

Wdrożenie nie jest jednolite. VPS i Public Cloud różnią się zarówno architekturą, jak i ekspozycją klienta. Liczba maszyn wirtualnych na hostach VPS jest większa, a wiele firm i osób prywatnych korzysta z VPS do infrastruktury testowej; prawdopodobieństwo przetestowania przez klienta kodu eksploatacyjnego na swojej maszynie wirtualnej jest bardzo wysokie, a wpływ jest również duży ze względu na liczbę maszyn wirtualnych na każdym hoście.

W przypadku VPS zakres na hosta jest ograniczony, a wpływ na klienta po restarcie pozostaje pod kontrolą. Partie mogą być uruchamiane szybko jedna po drugiej, co pozwala zabezpieczyć znaczną część parku maszynowego w ciągu pierwszych 24 godzin.

Public Cloud stanowi ekspozycję innego rzędu. Region skupia tysiące klientów, a host może obsługiwać krytyczne instancje. Największe regiony liczą setki, a nawet tysiące hostów ze złożonymi wirtualnymi infrastrukturami klientów. Decydujemy się na ustalenie priorytetów:według wielkości regionu

• : regiony o mniejszej gęstości są obsługiwane w pierwszej kolejności, aby potwierdzić solidność procedury na dużą skalę;według liczby narażonych klientów
• : regiony o dużym wolumenie są obsługiwane z większą szczegółowością, partia po partii, aby zminimalizować ryzyko.Progi zatrzymania i kontrola tempa

Każda fala restartów podlega

progowi zatrzymania: jeśli liczba jednocześnie awaryjnych hostów przekroczy zdefiniowany próg, fala zostaje wstrzymana. Próg ten jest ustalony na 15 hostów dla regionów o dużej gęstości (GRA, RBX, BHS) oraz na 5 hostów dla pozostałych. Zatrzymanie jest również wyzwalane o godzinie 06:00 lub na żądanie lokalnego centrum danych.To rozwiązanie pozwala uniknąć pogorszenia sytuacji awarii sprzętowej poprzez kontynuowanie restartowania hostów, których technicy DC nie zdążyli jeszcze obsłużyć. Wprowadza ono punkt regulacji między automatyzacją programową a fizyczną rzeczywistością w terenie.

Nierestartowanie jednocześnie dwóch instancji tego samego projektu: antykoligacja jako zabezpieczenie

Głównym ryzykiem dla naszych klientów podczas takiej operacji nie jest sam restart, lecz

jednoczesne przerwanie działania kilku instancji tego samego projektu, gwarantujących odporność aplikacji zdolną do poradzenia sobie z awarią dostawcy. Klient, który rozdzielił swoje obciążenia robocze na kilka hostów w celu zapewnienia wysokiej dostępności, nie powinien widzieć, jak wszystkie jego instancje przełączają się w tym samym czasie. Podjęto decyzję o wyjściu poza przestrzeganie reguł antykoligacji, które mogły zostać zdefiniowane we wdrożeniach klientów.W związku z tym dla każdego projektu klienta posiadającego instancje rozproszone na wielu hostach nasze orkiestratorzy obliczają

graf ko-lokalizacji. W żadnym momencie dwa hosty obsługujące instancje tego samego projektu nie są restartowane w tym samym oknie: definiowane są wzajemnie wykluczające się fale, a host musi wrócić do pracy przed uruchomieniem kolejnego w tej samej klasie antykoligacji.Ta antykoligacja jest stosowana w trybie

best effort: jest przestrzegana w większości przypadków, ale nie może być zagwarantowana w 100% w całej flocie. Celem pozostaje sekwencjonowanie wpływu tak, aby był on absorbowalny od strony aplikacji. Klienci, których wszystkie instancje znajdują się na jednym hoście, doświadczają punktowego przerwania, którego okno jest ogłaszane.Priorytetowa migracja na żywo usług i wrażliwych obciążeń roboczych

Za każdą instancją klienta znajdują się kontrolery, API, płaszczyzny danych, wewnętrzne bazy danych. Nieopanowany restart hostów obsługujących te usługi stworzyłby

zakleszczenia: niedostępna usługa wewnętrzna blokuje kolejne restarty, co blokuje patching. Ponadto niektóre usługi OVHcloud opierają się na maszynach wirtualnych hostowanych na instancjach Public Cloud. Uwzględnienie tych przypadków jest niezbędne, aby ograniczyć wpływ na klientów.Aby uniknąć tej kaskady, priorytet został odwrócony: dogłębna analiza zależności usług wewnętrznych jest przeprowadzana przed każdym restartem regionu.

Niektóre usługi wewnętrzne są migrowane na żywo. Ich maszyny wirtualne są przenoszone na żywo na już spatchowane hosty, łańcuch zależności jest utrzymywany w stanie dostępności, a następnie host jest zwalniany do restartu.Procedura ta jest długa i intensywnie zużywa zasoby sprzętowe oraz ludzkie. Musi ona zostać ograniczona do niewielkiej liczby maszyn wirtualnych, aby dotrzymać celu, jakim jest ograniczenie czasu trwania migracji.

Niektóre obciążenia wymagają szczególnej uwagi: w szczególności usługi

Cloud Databases (DBaaS), wewnętrzny Datalake oraz funkcje Observability są migrowane po jednej maszynie wirtualnej na raz, bez wyłączania więcej niż jednej maszyny jednocześnie, odkładając aktualizację ich hostów na jak najpóźniejszy termin. Ta płynna migracja pozwala uniknąć awarii kaskadowych usług i zapewnia, że narzędzia wspierające operacje pozostają dostępne.Incydenty techniczne i korekty w trakcie operacji

Operacja tej skali nie przebiega bez incydentów. Podczas kampanii napotkano i rozwiązano szereg problemów technicznych.

Maszyny wirtualne nieuruchamiające się po restarcie hosta

Pierwszy poważny incydent pojawił się już podczas pierwszej fali europejskiej: maszyny wirtualne nie uruchamiały się ponownie po restarcie ich hypervisora. Nova compute zgłaszał „Instance shutdown by itself” bez synchronizacji.

Przyczyna źródłowa została zidentyfikowana drugiego dnia: usługa libvirt-guests wchodziła w konflikt z nova compute i zatrzymywała instancje podczas restartu bez synchronizacji po stronie API. Zastosowana poprawka polega na wyłączeniu i zamaskowaniu libvirt-guests.service na hostach przed restartem. Od momentu wprowadzenia tej poprawki automatyczne restarty maszyn wirtualnych działają.Uszkodzenie danych w usługach synchronicznych

Wieczorem drugiego dnia wewnętrzny system monitorowania zgłosił

uszkodzone dane na kilku maszynach wirtualnych rozproszonych w 3 klastrach. Prawdopodobna przyczyna: wymuszony restart nastąpił w trakcie zapisu na dysk. Czas łagodnego wyłączenia został wydłużony do 60 sekund przed wymuszonym zabiciem procesu, aby dać czas na zakończenie operacji zapisu. Wdrożono skrypt automatycznego restartu maszyn wirtualnych, które pozostały wyłączone.Deadlock API w Paryżu

W nocy z drugiego na trzeci dzień API Nova i Neutron w Paryżu weszły w stan

wzajemnego zakleszczenia: API Neutron (ograniczone do 10 procesów) uległo nasyceniu pod wpływem serii zapytań z Nova, zwracając błędy HTTP 503 przez około dwie godziny. Poprawka polega na zwiększeniu liczby procesów roboczych Neutron z 10 do 30, a procesów Apache z 10 do 32. Strefy B w Paryżu i Mediolanie zostały przełożone na czas stabilizacji.Nasycenie wsparcia w BHS

W ośrodku BHS (Kanada) ruch API osiągnął

10-krotność zwykłego maksymalnego ruchu, nasycając Manager i wsparcie. Klienci odkryli wpływ awarii, zanim otrzymali komunikat. Ten przypadek konkretnie ilustruje reakcje łańcuchowe wewnątrz infrastruktury.Wszystkie te błędy i napotkane problemy zostały rozwiązane w ramach działań operacyjnych, ale zostaną uwzględnione przy wdrażaniu odpowiednich ulepszeń w sposób trwały.

Restartowanie i interwencje sprzętowe

Restart dziesiątek tysięcy maszyn wiąże się również z aspektem

sprzętowym. Istnieje wskaźnik awaryjności nieodłącznie związany z każdym restartem serwera. Podczas pierwszej nocy około 20 do 30 hostów na 6000 nie uruchomiło się samodzielnie: uszkodzone kości pamięci, konfiguracja BIOS, nieaktywny interfejs sieciowy. W Stanach Zjednoczonych w przypadku kilku hostów konieczne było wyjęcie baterii CMOS i rozładowanie zasilania przed ponownym włączeniem — jest to powtarzający się profil sprzętowy.Każdy ośrodek dysponuje

technikami centrum danych zmobilizowanymi do wsparcia podczas kampanii. Ich rola:interwencja w trybie pilnym

• w przypadku hostów, które nie przeszły restartu, zgłoszonych przez orkiestratorów;wymiana uszkodzonych części
• (dyski, kości pamięci, zasilacze);wykonywanie czynności fizycznych
• , których żadne narzędzie nie może zautomatyzować: fizyczny twardy restart, sprawdzanie kontrolek, interwencja w szafie rack.Technicy centrum danych działają w

trybie interwencji priorytetowej na uszkodzonych hostach, w koordynacji z zespołami Run/SRE, które ustalają priorytety w zależności od ekspozycji klienta na danym hoście. Host, który obsługuje krytyczne instancje i nie powraca do działania, ma pierwszeństwo przed wolnym hostem. Ta skrzyżowana priorytetyzacja — programowa i fizyczna — jest tym, co utrzymuje tempo operacji.Komunikacja i wsparcie: informowanie dotkniętych klientów

Jednostronna aktualizacja o kontrolowanym wpływie nie może zostać przeprowadzona bez proporcjonalnego wysiłku komunikacyjnego.

Ukierunkowana i stopniowa komunikacja

W obliczu dynamiki modelu follow the sun, globalna i niezróżnicowana komunikacja nie miałaby żadnego sensu. Przyjętą strategią była

ukierunkowana i stopniowa komunikacja: skierowana wyłącznie do klientów, których instancje są hostowane na serwerach zaplanowanych do restartu, i uruchamiana w miarę postępu operacji, region po regionie, fala po fali.Początkowo podjęto decyzję o

nieuruchamianiu publicznej strony statusu, aby nie ujawniać sekwencji wdrażania. Komunikacja odbywa się poprzez komunikaty kierowane za pośrednictwem naszego portalu wsparcia, wraz z wysyłką wiadomości e-mail do klientów posiadających poziom wsparcia Business i Enterprise.Wniosek: niektóre wiadomości nie są dostarczane

Narzędzia komunikacji mają ograniczenia techniczne. W przypadku regionów o dużym wolumenie, takich jak GRA6 (prawie 90 000 niepowiadomionych klientów), masowa wysyłka wiadomości e-mail została odrzucona, aby uniknąć mnożenia zgłoszeń do wsparcia.

W obliczu tego faktu, drugiego dnia podjęto decyzję o

zwrocie: wdrożeniu warunkowego banera w Managerze za pomocą feature flippingu — jeśli zalogowany użytkownik znajduje się na liście dotkniętych kont klientów (NIC), wyświetla się komunikat informacyjny. Prace programistyczne przeprowadzono w ciągu dnia, a baner wdrożono trzeciego dnia. W tym samym czasie utworzono również stronę statusu Public Cloud.Pomimo tych środków, niektóre wiadomości nie dotarły do adresatów: przestarzałe adresy kontaktowe, przefiltrowane powiadomienia, rozbieżność między planowanym czasem restartu a czasem wysyłki. Niektórzy klienci odkryli wpływ awarii bez wcześniejszego powiadomienia. Te punkty krytyczne zostały zidentyfikowane jako priorytetowe obszary do poprawy po zakończeniu początkowego planu mitygacji.

Wsparcie jako kanał ostatniej szansy

Dla klientów niepoinformowanych lub potrzebujących wyjaśnień

obsługa klienta została wzmocniona i przygotowana: wcześniejszy briefing na temat kontekstu operacji, dostęp w czasie rzeczywistym do stanu postępu prac według regionu i hosta, przyspieszone przetwarzanie zgłoszeń związanych z kampanią za pośrednictwem dedykowanego kanału.Obsługa klienta nadrabia to, czego nie udało się przekazać za pomocą zautomatyzowanych powiadomień. Nie zastępuje ona komunikacji, lecz rekompensuje niektóre jej braki.

Oś czasu operacji

Timeline de l’opération

Perspektywy

CVE-2026-53359 narażała naszych klientów i naszą infrastrukturę na ryzyko. Plan działań mitygacyjnych spowodował wpływ na klienta — ograniczony, uszeregowany, zapowiedziany, ale realny. Bardziej szczegółowa komunikacja podczas realizacji planu działań, dopóki infrastruktura nie została spatchowana, znacząco zwiększyłaby ryzyko dla naszych klientów, skłaniając niektórych z nich do „przetestowania” publicznie dostępnego exploita.

Restart floty o zasięgu globalnym bez żadnego wpływu nie był osiągalnym celem. Celem było zatem najmniejsze możliwe oddziaływanie, zgodne z bezpieczeństwem całego parku maszynowego.

Łatanie i restartowanie wszystkich hostów Public Cloud oraz VPS nigdy wcześniej nie było wykonywane przy tak krótkim czasie realizacji. Ta procedura awaryjna została wdrożona ze względu na ryzyko związane z podatnością. Poprzednie przypadki były zawsze obsługiwane poprzez stopniowy restart z wykorzystaniem naturalnego cyklu rotacji maszyn wirtualnych w infrastrukturze, w połączeniu z doraźnymi migracjami na żywo (live-migrate), zaplanowanymi w długim okresie.

Zespoły zaangażowane w tę operację dokonały wyczynu, osiągając bardzo rozsądną liczbę awarii i wpływów na klientów w proporcji do skali przedsięwzięcia. Jednakże, świadomi, że w nadchodzących miesiącach mogą pojawić się kolejne publikacje dotyczące podatności jądra, wydaje się pewne, że ta procedura awaryjna będzie musiała zostać powtórzona. Następnym razem musimy działać lepiej, zarówno w zakresie ograniczania bezpośredniego wpływu restartów, jak i informowania klientów z wyprzedzeniem oraz procedur wsparcia dla klientów dotkniętych operacjami. Dlatego w nadchodzących dniach i tygodniach zidentyfikujemy główne problemy u naszych klientów, którzy doświadczyli złożonych awarii, oraz przeanalizujemy napotkane trudności wewnętrznie, w ramach analizy pośmiertnej (post-mortem), w celu usprawnienia naszych procedur w przyszłości.