Feedback sobre uma operação de correção conduzida numa semana em todo o nosso parque KVM, segundo uma estratégia de patching cujo objetivo central foi minimizar o impacto nos serviços dos nossos clientes.

Uma vulnerabilidade no subsistema de virtualização

Na terça-feira, 7 de julho, no início da tarde, foi reportado um alerta de segurança relativo à CVE-2026-53359, uma vulnerabilidade do tipo use-after-free que afeta o subsistema de shadow-paging do KVM x86 no kernel Linux. A falha, com vários anos, foi tornada pública a 6 de julho; blogs de outros fornecedores de cloud surgiram logo no dia 7.

O KVM constitui o motor de virtualização no qual assenta a imensa maioria das instâncias alojadas na OVHcloud. O mecanismo é o seguinte: quando ocorre uma modificação externa de uma Page Directory Entry (PDE), a entrada RMAP pode manter uma referência para uma página de memória já libertada. O kernel desreferencia então esta página obsoleta, o que pode levar a uma falha do hipervisor ou, nos cenários mais desfavoráveis, a uma elevação de privilégio do lado do anfitrião. O exploit é reprodutível: um teste interno num anfitrião não corrigido provoca uma falha em cerca de dois minutos.

Todos os kernels Linux x86 anteriores ao commit de correção são afetados, sem distinção de distribuição. O patch oficial é retroportado para os nossos kernels de produção Debian.

3 riscos principais a considerar:

• Um cliente VPS utiliza o exploit para bloquear o host que executa a sua máquina virtual: falha e reinicialização não controlada de várias centenas de máquinas virtuais de clientes.
• Cenário idêntico nas instâncias do Public Cloud, o impacto é semelhante, mas o número de máquinas virtuais por host é mais restrito e as máquinas virtuais são mais potentes e utilizadas para sistemas mais sensíveis (bases de dados, gestor de filas, balanceador de carga, etc.). Estes sistemas são frequentemente utilizados em arquiteturas de aplicações compostas com dependências complexas.
• Probabilidade da publicação futura de um exploit de controlo do host, o que aumentaria imediatamente o nível de risco para um nível inaceitável devido ao impacto na confidencialidade dos dados dos clientes e na integridade da infraestrutura.

Para a OVHcloud, o perímetro representa dezenas de milhares de servidores anfitriões hipervisores, alojando cerca de um milhão de máquinas virtuais. A questão não é, portanto, determinar se é necessário aplicar patches, mas como conduzir esta operação a tal escala, sabendo que um impacto nulo no cliente não é alcançável.

As opções em cima da mesa para mitigar o risco

-1%

Aguardar pelos kernels corrigidos oficiais

Esta opção tornava-nos dependentes de um calendário de terceiros que nos deixava em estado de risco por um período não controlado. Descartámo-la rapidamente tendo em conta o risco.

2. Live patch

Aplicar um live patch requer autorizar este tipo de operação na configuração do kernel, o que permite, por construção, poder modificar o seu comportamento em tempo real, levando consequentemente a uma redução do seu nível de endurecimento, limitando as capacidades de deteção em caso de compromisso do mesmo. Além disso, o live patch é um procedimento sensível por natureza, podendo levar a um estado instável à escala do parque. É uma opção que permite ganhar tempo enquanto se aguarda uma solução duradoura. Decidimos não fazer este compromisso que teria aumentado muito fortemente o risco em caso de publicação de um exploit de controlo do host.

3. Mitigação por desativação da virtualização aninhada

Desativar a virtualização aninhada nos hosts permite tornar o exploit inoperante. Não temos visibilidade sobre a utilização desta funcionalidade pelos nossos clientes, por isso é impossível determinar o impacto nos serviços dos clientes, e esta funcionalidade é necessária para manter a capacidade de migração ao vivo de uma instância de um host físico para outro. Descartamos esta via rapidamente.

4. Live migrate

Organizar uma migração ao vivo das máquinas virtuais, a partir de hosts vulneráveis para hosts vazios que foram corrigidos entretanto. Esta opção é muito satisfatória em termos de continuidade de serviço, pois a migração é feita sem impacto nas máquinas virtuais, com exceção de um desempenho reduzido durante a migração. Esta opção demora muito tempo, devido à cópia das máquinas virtuais de host para host; não é realisticamente utilizável à escala do parque e do desejo de proteger os nossos clientes em poucos dias em vez de vários meses. Decidimos manter esta opção apenas para algumas máquinas virtuais críticas, uma vez que cada migração ao vivo provoca um atraso significativo no desenrolar dos lotes.

5. Backport do patch nos nossos kernels e reinício de todos os hosts

É finalmente esta opção que será retida e que será detalhada no resto do artigo.

Terça-feira à tarde: ativação e organização da célula de crise

Assim que a vulnerabilidade é confirmada, a prioridade é construir uma resposta estruturada e coordenada; os analistas responsáveis por esta primeira análise compreendem muito rapidamente os desafios dos dias seguintes. A informação é difundida internamente no início da tarde. Vários espaços de coordenação são abertos: um para a coordenação técnica, um para a coordenação de crise, um para as operações nos EUA, um para a comunicação com o cliente e o suporte. Ao mesmo tempo, as equipas de Kernel preparam e fazem o backport da correção; o primeiro kernel corrigido é entregue à noite.

Os testes de validação são realizados em ambiente de teste durante a noite. O patch é confirmado, o exploit já não causa falhas nos hipervisores corrigidos e os testes de QA passam com o kernel corrigido.A célula de crise evolui para um acompanhamento da implementação e é depois gerida pelo NOC (Network Operations Center), que assume o papel de coordenador operacional: acompanhamento do progresso global, arbitragem das prioridades entre regiões e serviços, manutenção da visão de conjunto. A execução é assegurada pelos especialistas em Public Cloud e VPS

, que operam os reinícios, live-migrate e restrições de anti-afinidade. A separação entre coordenação e execução é voluntária: o NOC coordena, as equipas operacionais agem e comunicam as métricas e eventos técnicos necessários para a coordenação.A sincronização com o Apoio ao cliente (estado de progresso em tempo real para responder aos clientes impactados) e as equipas de Segurança

(monitorização da vulnerabilidade, validação do perímetro e dos critérios de fim de operação) é assegurada continuamente.A operação seguindo o modelo follow the sun, a célula funciona em 24/7 com uma rotação por zona geográfica. Três pontos de sincronização

são realizados todos os dias, cobrindo as transições de zonas. Estes reúnem o NOC, os especialistas operacionais, o Apoio ao cliente e a Segurança para: partilhar o estado de progresso por região, transmitir o testemunho entre zonas (o que funcionou, os ajustes de procedimento com base no feedback do terreno) e arbitrar as prioridades da próxima sequência.A célula completa reúne, por rotação 24/7: as equipas Kernel & Virtualization (análise do patch, backport, validação), VPS e Public Cloud (implementação), NOC (gestão), Run & SRE (orquestração, anti-afinidade, live migration), Datacenter Operations (intervenções de hardware), Apoio ao cliente (solicitações dos clientes), Segurança (monitorização, perímetro, fim de operação) e Comunicação

(transparência, notificações direcionadas).O objetivo atribuído é claro: aplicar o patch e reiniciar os hosts afetados o mais rapidamente possível para reduzir a janela de vulnerabilidade, minimizando o impacto nos serviços

. A restrição principal reside na escala: dezenas de milhares de máquinas a processar, em todos os continentes, sabendo que um tratamento caso a caso é materialmente impossível a este volume.

O risco principal nesta etapa é a exploração da vulnerabilidade, levando a uma falha do host não corrigido. A célula de crise decide aplicar o patch globalmente antes da fase de reinício. No caso de uma exploração da vulnerabilidade, o crash de um anfitrião levará ao seu reinício e à tomada em consideração automática do patch. Além disso, existe um risco de a CVE ser explorada para um controlo malicioso do anfitrião. Nenhum código de exploração está disponível publicamente, mas sabemos que é apenas uma questão de tempo até que um investigador consiga utilizar a vulnerabilidade para assumir o controlo do anfitrião. Sendo este cenário catastrófico, sabemos que cada minuto conta.

Uma decisão assumida: uma aplicação de patches unilateral com impacto controladoO Comité Executivo valida o Go/No-Go

à noite: a primeira região será tratada na manhã seguinte. Para este número de máquinas, não existe nenhum cenário sem impacto. Negociar uma janela de manutenção com cada cliente, verificar cada dependência, orquestrar cada reinício à medida — são etapas materialmente incompatíveis com um prazo aceitável face ao risco de segurança.A célula de crise toma, portanto, uma decisão assumida: uma aplicação de patches unilateral com impacto controlado

• , aplicada sem esperar pelo acordo individual de cada cliente, sabendo que alguns serviços sofrerão uma interrupção. O raciocínio baseia-se em três pontos:
• não aplicar o patch expõe todo o parque a uma falha de gravidade elevada;
• um tratamento caso a caso prolongaria os prazos e deixaria a maioria dos anfitriões vulneráveis durante semanas;

uma ação rápida e global protege o maior número, mesmo que isso implique impactar uma minoria de forma temporária.A prioridade deixa então de ser evitar o impacto, mas sim minimizá-lo, diluí-lo e torná-lo previsível

. É esta linha que estrutura toda a operação: follow the sun, priorização das regiões e planeamento anti-afinidade.

Quarta-feira, 8 de julho: início a partir de Sydney

• A escolha de Sydney para testar a implementação é trivial: o número de anfitriões é limitado e o período de implementação em HNO local (durante a noite) corresponde aos horários de expediente das equipas na Europa. Começar pela região mais a leste permite:
• operar na zona menos carregada;
• validar o procedimento em condições reais, à escala reduzida, antes da industrialização;

recolher os primeiros feedbacks antes de lançar as regiões europeias e norte-americanas.As primeiras vagas de patch + reboot são aplicadas nos hosts VPS

na Austrália. A região SYD2 está concluída no início da tarde (hora de Paris), sem incidentes. Os procedimentos são adaptados com base nos feedbacks do terreno.Assim que o procedimento é estabilizado, o follow the sun

é iniciado: cada região assume o comando por sua vez, na sua manhã local, transmitindo o contexto à seguinte. A primeira vaga europeia (RBX, GRA6, WAW, DE, SBG, MIL, UK) é lançada na mesma noite, às 18h30 hora de Paris.

Dois perímetros, duas exposições: VPS primeiro, Public Cloud depois

A implementação não é uniforme. VPS e Public Cloud diferem tanto pela sua arquitetura como pela sua exposição ao cliente. O número de máquinas virtuais em hosts VPS é mais elevado e muitas empresas e particulares utilizam VPS para infraestruturas de teste; a probabilidade de um teste de cliente do código de exploração na sua máquina virtual é muito elevada e o impacto também o é devido ao número de máquinas virtuais em cada host.No VPS

, o perímetro por host é contido e o impacto no cliente por reinicialização permanece controlado. Os lotes podem ser encadeados rapidamente, o que permite assegurar uma grande parte do parque logo nas primeiras 24 horas.O Public Cloud

• apresenta uma exposição de outra ordem. Uma região concentra milhares de clientes, e um host pode alojar instâncias críticas. As regiões mais importantes contam com centenas ou até milhares de hosts com infraestruturas de cliente virtuais complexas. Decidimos priorizar:por dimensão da região
• : as regiões com menor densidade são tratadas primeiro, a fim de validar a robustez do procedimento à escala;por número de clientes expostos

: as regiões com elevado volume são orquestradas com uma granularidade mais fina, lote a lote, para diluir o risco.

Limiares de paragem e controlo do tempoCada vaga de reinícios está sujeita a um limiar de paragem: se o número de anfitriões em falha simultânea exceder um limiar definido, a vaga é suspensa. Este limiar é fixado em 15 anfitriões para as regiões de alta densidade (GRA, RBX, BHS) e em 5 anfitriões

para as restantes. Uma paragem é também acionada às 06h00 ou a pedido do centro de dados local.

Este dispositivo permite não agravar uma situação de falha de hardware ao continuar a reiniciar anfitriões que os técnicos do DC ainda não conseguiram tratar. Introduz um ponto de regulação entre a automatização lógica e a realidade física do terreno.

Não reiniciar simultaneamente duas instâncias do mesmo projeto: a anti-afinidade como salvaguardaO principal risco para os nossos clientes durante uma operação deste tipo não é o reinício em si, é a interrupção simultânea

de várias instâncias do mesmo projeto que garante uma resiliência aplicacional capaz de fazer face a uma falha do fornecedor. Um cliente que tenha distribuído as suas cargas de trabalho por vários anfitriões para garantir a sua alta disponibilidade não deve ver o conjunto das suas instâncias a falhar ao mesmo tempo. Foi tomada a decisão de ir além do cumprimento das regras de anti-afinidade que possam ter sido definidas nas implementações dos clientes.Assim, para cada projeto de cliente que disponha de instâncias distribuídas por vários anfitriões, os nossos orquestradores calculam um grafo de co-localização. Em momento algum dois anfitriões que alojem instâncias do mesmo projeto são reiniciados na mesma janela: são definidas vagas mutuamente exclusivas

e um anfitrião tem de estar de volta ao serviço antes do lançamento do seguinte na mesma classe de anti-afinidade.Esta anti-afinidade é aplicada em best effort

: é respeitada na maioria dos casos, mas não pode ser garantida a 100% em todo o parque. O objetivo continua a ser sequenciar o impacto para que seja absorvível do lado da aplicação. Os clientes cujas instâncias residem todas num único anfitrião sofrem uma interrupção pontual, cuja janela é anunciada.

Live-migration prioritária de serviços e cargas de trabalho sensíveisPor trás de cada instância de cliente encontram-se controladores, APIs, planos de dados e bases internas. Um reinício não controlado dos anfitriões que alojam estes serviços criaria deadlocks

: um serviço interno indisponível bloqueia a continuação dos reinícios, o que bloqueia a aplicação de patches. Além disso, alguns serviços OVHcloud baseiam-se em máquinas virtuais alojadas nas instâncias Public Cloud. Ter em conta estes casos é indispensável para limitar os impactos nos clientes.Para evitar esta cascata, a prioridade é invertida: é feita uma análise aprofundada das dependências dos serviços internos antes de cada reinicialização de região. Alguns serviços internos são migrados em tempo real.

As suas máquinas virtuais são movidas a quente para anfitriões já corrigidos, a cadeia de dependências é mantida disponível e, em seguida, o anfitrião é libertado para reinicialização.

Este procedimento é longo e consome intensivamente recursos materiais e humanos. Deve ser limitado a um número reduzido de máquinas virtuais para respeitar o objetivo de conter a migração no tempo.Algumas cargas de trabalho requerem uma atenção especial: em particular, os serviços de Cloud Databases (DBaaS), o Datalake interno e as funções de Observability são migrados uma VM de cada vez

, sem desligar mais do que uma máquina simultaneamente, adiando a atualização dos seus anfitriões o máximo de tempo possível. Esta migração suave permite evitar falhas em cascata nos serviços e garantir que as ferramentas de suporte às operações permanecem disponíveis.

Incidentes técnicos e ajustes durante a operação

Uma operação desta dimensão não decorre sem incidentes. Foram encontrados e resolvidos vários problemas técnicos durante a campanha.

VMs que não reiniciam após a reinicialização do anfitriãoO primeiro incidente grave surgiu logo na primeira vaga europeia: algumas máquinas virtuais não reiniciavam após a reinicialização do seu hipervisor. O Nova compute sinalizava «Instance shutdown by itself» sem sincronização. A causa raiz foi identificada no segundo dia: o serviço libvirt-guests entrava em conflito com o nova compute e parava as instâncias durante a reinicialização sem sincronização do lado da API. A correção aplicada consiste em desativar e mascarar

o libvirt-guests.service nos anfitriões antes da reinicialização. A partir desta correção, os reinícios automáticos das VMs funcionam.

Corrupção de dados em serviços síncronosNa noite do segundo dia, o sistema de monitorização interno sinalizou dados corrompidos em várias VMs distribuídas por 3 clusters. A causa provável: a reinicialização forçada ocorria a meio da escrita no disco. O graceful shutdown foi então alargado para 60 segundos

antes do encerramento forçado, para dar tempo às escritas para terminarem. Foi implementado um script de reinício automático das VMs que permaneceram desligadas.

Deadlock de API em ParisNa noite do segundo para o terceiro dia, as APIs Nova e Neutron em Paris entram em deadlock mútuo: a API Neutron (limitada a 10 processos) satura sob uma rajada de pedidos da Nova, devolvendo HTTP 503 durante cerca de duas horas. A correção consiste em aumentar os workers Neutron de 10 para 30 e os processos Apache de 10 para 32. As zonas B de Paris e Milão são adiadas

enquanto se estabilizam.

Saturação do suporte em BHSNo local de BHS (Canadá), o tráfego da API atinge 10 vezes o tráfego máximo habitual

, saturando o Gestor e o suporte. Alguns clientes descobriram o impacto antes de terem recebido a comunicação. Este caso ilustra concretamente as reações em cadeia no seio da infraestrutura.

Estes erros e problemas encontrados foram todos geridos no âmbito das operações, mas serão tidos em conta para implementar as melhorias adaptadas de forma duradoura.

Os reinícios e as intervenções de hardwareUm reinício de dezenas de milhares de máquinas implica também uma dimensão de hardware. Existe uma taxa de avaria inerente a qualquer reinício de servidor. Na primeira noite, cerca de 20 a 30 anfitriões em 6 000 não voltaram sozinhos: módulos de memória defeituosos, configuração da BIOS, interface de rede inativa. Nos Estados Unidos, vários anfitriões necessitaram de uma remoção da bateria CMOS

e de uma drenagem da alimentação antes de voltar a ligar — um perfil de hardware recorrente.Cada local dispõe de técnicos de centro de dados

• mobilizados como reforço durante a campanha. O seu papel:intervir com urgência
• nos anfitriões com falha de reinício sinalizados pelos orquestradores;substituir as peças defeituosas
• (discos, módulos de memória, fontes de alimentação);efetuar as ações de proximidade que nenhuma ferramenta pode automatizar: hard reboot

físico, verificação das luzes indicadoras, intervenção na baía.Os técnicos do centro de dados operam em modo de intervenção prioritária nos anfitriões com falha

, em coordenação com as equipas de Run/SRE que priorizam de acordo com a exposição do cliente do anfitrião. Um anfitrião que suporte instâncias críticas e que não recupere tem prioridade sobre um anfitrião vazio. Esta priorização cruzada — lógica e física — é o que mantém o ritmo da operação.

Comunicação e suporte: informar os clientes impactados

Uma atualização (patching) unilateral com impacto controlado não pode ser concebida sem um esforço de comunicação proporcional.

Uma comunicação direcionada e progressivaPerante a dinâmica do follow the sun, uma comunicação global e indiferenciada não teria feito qualquer sentido. A estratégia adotada foi uma comunicação direcionada e progressiva

: dirigida apenas aos clientes cujas instâncias estão alojadas nos anfitriões programados para reinício, e acionada à medida que a operação avançava, região por região, vaga por vaga.Inicialmente, é tomada a decisão de não ativar uma status-page pública, para não expor a sequência de implementação. As comunicações são feitas através de targeted communications

no nosso portal de Suporte, com o envio de e-mails aos clientes com um nível de Suporte Business e Enterprise.

Constatação: algumas mensagens não são entregues

As ferramentas de comunicação têm limites técnicos. Para as regiões com elevado volume como a GRA6 (quase 90 000 clientes não contactados), o envio massivo de e-mails é descartado para evitar a multiplicação de pedidos de suporte.Perante esta constatação, é decidido um pivot no segundo dia: implementar uma faixa condicional no Manager através de um feature flipping

— se o utilizador ligado constar na lista de contas de cliente (NICs) impactadas, é apresentada uma mensagem de informação. O desenvolvimento é realizado durante o dia e a faixa é implementada no terceiro dia. Uma página de estado (status-page) do Public Cloud é também criada nesse momento.

Apesar destes dispositivos, algumas mensagens não chegaram aos seus destinatários: endereços de contacto obsoletos, notificações filtradas, desfasamento entre a hora prevista do reinício e a hora de envio. Alguns clientes descobriram o impacto sem terem sido avisados previamente. Estes pontos de rutura são identificados como eixos de melhoria prioritários após o plano de mitigação inicial.

O suporte como canal de último recursoPara os clientes não informados, ou que solicitem esclarecimentos, o apoio ao cliente foi reforçado e preparado

: briefing prévio sobre o contexto da operação, acesso em tempo real ao estado de progresso por região e por anfitrião, tratamento acelerado dos pedidos relacionados com a campanha através de um circuito dedicado.

O apoio compensa o que as notificações automatizadas não conseguiram transmitir. Não substitui a comunicação, compensa algumas das suas lacunas.

Perspetivas

A CVE-2026-53359 colocava os nossos clientes e as nossas infraestruturas em risco. O plano de ação de mitigação resultou num impacto no cliente — contido, sequenciado, anunciado, mas real. Comunicar de forma mais detalhada durante a execução do plano de ação, enquanto a infraestrutura não estava corrigida, teria aumentado significativamente o risco para os nossos clientes, levando alguns deles a «testar» o exploit disponível publicamente.

Reiniciar um parque de dimensão mundial com impacto nulo não era um objetivo alcançável. O objetivo era, portanto, a menor amplitude de impacto compatível com a segurança de todo o parque.

Corrigir e reiniciar todos os hosts Public Cloud e VPS nunca tinha sido feito com esta restrição de tempo. Este procedimento de emergência foi implementado tendo em conta o risco associado à vulnerabilidade. Os casos anteriores tinham sido sempre tratados através de um reinício progressivo, utilizando a taxa de rotação natural das máquinas virtuais na infraestrutura, combinado com live-migrates ad-hoc planeados a longo prazo.

As equipas envolvidas nesta operação realizaram um feito com um número de falhas e de impacto no cliente muito razoável em proporção à dimensão do projeto. No entanto, conscientes de que os próximos meses poderão dar lugar a outras publicações de vulnerabilidades do kernel, parece estabelecido que este procedimento de emergência terá de se repetir. Teremos de fazer melhor da próxima vez, tanto no controlo do impacto bruto dos reinícios como na informação prévia aos clientes e no procedimento de acompanhamento dos clientes impactados durante as operações. Assim, nos dias e semanas que se seguem, iremos identificar os impactos principais nos nossos clientes que sofreram falhas complexas, e trabalhar os problemas encontrados durante as operações internamente, em post-mortem, com o objetivo de melhorar os nossos procedimentos no futuro.