Relatório sobre uma operação de correção realizada 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

No início da tarde de 7 de julho, uma terça-feira, foi emitido 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, que já existe há vários anos, foi tornada pública a 6 de julho; a 7 de julho surgiram publicações em blogues de outros fornecedores cloud.

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. Então, o kernel desreferencia esta página obsoleta, o que pode levar a uma falha do hipervisor ou, pior, a uma elevação de privilégios do lado do host. O exploit é reproduzível: um teste interno num host sem patch provoca uma falha em cerca de dois minutos.

Todos os kernels Linux x86 anteriores ao commit de correção são afetados, independentemente da distribuição. O patch oficial é retroaplicado aos nossos kernels de produção Debian.

3 principais riscos a considerar:

• Um cliente VPS usa o exploit para bloquear o host que executa a sua máquina virtual: crash e reboot não controlado de várias centenas de máquinas virtuais 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, gestores de filas, distribuidores de carga, etc.). Em geral, estes sistemas são usados em arquiteturas aplicativas compósitas com dependências complexas.
• Probabilidade de que venha a ser divulgado um exploit que permita a tomada de controlo do host, o que aumentaria imediatamente o nível de risco para um patamar 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 hosts hipervisores, que alojam cerca de um milhão de máquinas virtuais. A questão não é, portanto, determinar se é necessário aplicar patches, mas como levar a cabo essa operação a tal escala, sabendo que não é possível evitar impactos no cliente.

Opções em cima da mesa para mitigar o risco

1: Aguardar pelos kernels oficiais com o patch aplicado

Esta opção deixar-nos-ia dependentes de um calendário de terceiros, o que nos colocaria numa situação de risco durante um período indeterminado. Descartámo-la rapidamente tendo em conta o risco.

2: Live patch

A aplicação de um live patch requer que este tipo de operação seja autorizado na configuração do kernel, o que permite, por definição, alterar o seu comportamento em tempo real, o que, por sua vez, implica uma redução do seu nível de segurança, limitando as capacidades de deteção em caso de comprometimento do mesmo. Além disso, o live patch é um procedimento sensível por natureza, pois pode 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 seguir esta via que teria aumentado fortemente o risco em caso de publicação de um exploit de tomada de controlo do host.

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

A desativação da virtualização aninhada nos hosts permite tornar o exploit ineficaz. 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 live migration de uma instância de um host físico para outro. Descartámos rapidamente esta opção.

4: Live migration

Organizar uma live migration das máquinas virtuais, a partir de hosts vulneráveis para hosts vazios que foram entretanto corrigidos. Esta opção é muito satisfatória em termos de continuidade de serviço, já que a migração é feita sem impacto nas máquinas virtuais, com exceção de um desempenho reduzido durante a migração. Esta via leva muito tempo, devido à cópia das máquinas virtuais de host para host, pelo que 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 live migration provoca um atraso significativo na execução dos batches.

5: Retroaplicação do patch aos nossos kernels e reboot de todos os hosts

É esta opção que acabará por ser escolhida e que será detalhada na sequência do artigo.

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

Assim que se dá a confirmação da vulnerabilidade, 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. Abrem-se vários espaços de coordenação: 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 Kernel preparam e fazem a retroaplicação 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 controlo de qualidade são bem-sucedidos com o kernel corrigido.

A célula de crise passa a acompanhar a implementação e a ser coordenada pelo Network Operations Center (NOC), que assume o papel de coordenador operacional: acompanhamento do avanço global, definição de prioridades entre regiões e serviços, e manutenção de uma visão de conjunto. A execução é assegurada pelos especialistas em Public Cloud e VPS, que operam os reboots, as live migrations e as restrições de anti-afinidade. A separação entre coordenação e execução é voluntária: o NOC coordena, enquanto as equipas operacionais agem e comunicam à coordenação as métricas e os eventos técnicos necessários.

A sincronização com o Apoio ao Cliente (estado de progresso em tempo real para responder aos clientes afetados) e com as equipas de Segurança (monitorização da vulnerabilidade, validação do perímetro e dos critérios de fim de operação) é assegurada de forma contínua.

Uma vez que a operação se insere no modelo «follow the sun», a célula funciona em modo 24/7, com rotações por zona geográfica. Realizam-se todos os dias três pontos de sincronização que abrangem 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, passar o testemunho entre zonas (o que funcionou, com os ajustes de procedimentos com base no feedback recebido do terreno) e decidir as prioridades da sequência seguinte.

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 (coordenaçã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 é claro: aplicar o patch e reiniciar os hosts afetados o mais rapidamente possível, para reduzir a janela de vulnerabilidade e minimizar o impacto sobre os serviços. O principal desafio prende-se com a escala: dezenas de milhares de máquinas a tratar, em todos os continentes, tendo em conta que, com este volume, é fisicamente impossível tratar cada caso de forma individual.

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 exploração da vulnerabilidade, o crash de um host levará ao seu reinício e à aplicação automática do patch. Além disso, existe um risco de a CVE ser explorada para uma tomada de controlo maliciosa do host. Não há nenhum código de exploração disponível publicamente, mas sabemos que é apenas uma questão de tempo até que alguém consiga utilizar a vulnerabilidade para assumir o controlo do host. Como se trata de um cenário catastrófico, sabemos que cada minuto conta.

Uma decisão assumida: um patching unilateral com impacto controlado

Durante a noite, o Comité Executivo valida o Go/No-Go: 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 reboot à medida — são etapas incompatíveis com um prazo aceitável face ao risco de segurança.

Portanto, a célula de crise toma uma decisão: um patching unilateral com impacto controlado, aplicado 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:

• a não-aplicação do 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 hosts vulneráveis durante semanas;
• uma ação rápida e abrangente protege o maior número possível de utilizadores, mesmo que isso implique afetar temporariamente uma minoria.

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 é óbvia: o número de hosts é 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 sobrecarregada;
• validar o procedimento em condições reais, à escala reduzida, antes da industrialização;
• recolher os primeiros feedbacks antes do lançamento das regiões europeias e norte-americanas.

As primeiras fases de patch + reboot são aplicadas nos hosts VPS na Austrália. A região SYD2 é concluída no início da tarde (hora de Paris), sem incidentes. Os procedimentos são adaptados com base nos feedbacks recebidos do terreno.

Assim que o procedimento é estabilizado, dá-se início ao «follow the sun»: cada região assume o comando por sua vez, na manhã local, transmitindo o contexto à região seguinte. A primeira fase 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 usam VPS para infraestruturas de teste; a probabilidade de um cliente testar o 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 por reboot para o cliente mantém-se 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 virtuais complexas. Decidimos dar prioridade:

• 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 ritmo

Cada fase de reboots está sujeita a um limiar de paragem: se o número de hosts em falha simultânea exceder um limiar definido, a fase é suspensa. Este limiar é fixado em 15 hosts para as regiões de alta densidade (GRA, RBX, BHS) e em 5 hosts para as restantes. Também é acionada uma paragem às 6h00 ou a pedido do datacenter local.

Este mecanismo permite evitar que uma falha de hardware se agrave, ao continuar-se a reiniciar os hosts que os técnicos dos datacenters ainda não conseguiram resolver. De resto, ele 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 salvaguarda

O principal risco para os nossos clientes durante uma operação deste tipo não é o reboot em si. É, sim, a interrupção simultânea de várias instâncias de um mesmo projeto que garantem a resiliência aplicativa capaz de fazer face a uma falha do fornecedor. Um cliente que tenha distribuído as suas cargas de trabalho por vários hosts para garantir a sua alta disponibilidade não deve ver o conjunto das suas instâncias falhar ao mesmo tempo. Tomou-se 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 que disponha de instâncias distribuídas por vários hosts, os nossos orquestradores calculam um grafo de colocalização. Em momento algum são reiniciados, na mesma janela, dois hosts que executem instâncias do mesmo projeto: são definidas fases mutuamente exclusivas, e um host tem de estar novamente em serviço antes do arranque 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 se encontram todas num único host sofrem uma interrupção pontual, cujo período é anunciado.

Live migration prioritária de serviços e cargas de trabalho sensíveis

Por trás de cada instância de cliente encontram-se controladores, API, planos de dados e bases internas. Um reboot não controlado dos hosts que alojam estes serviços criaria deadlocks: um serviço interno indisponível bloqueia a continuação dos reboots, o que, por sua vez, bloqueia o patching. Além disso, alguns serviços OVHcloud baseiam-se em máquinas virtuais alojadas nas instâncias Public Cloud. É indispensável ter em conta estes casos para limitar o impacto nos clientes.

De modo a evitar este efeito cascata, a prioridade é invertida: faz-se uma análise aprofundada das dependências dos serviços internos antes de cada reboot de região. Alguns serviços internos são objeto de live migration. As máquinas virtuais são movidas a quente para hosts já corrigidos, a cadeia de dependências é mantida disponível e, em seguida, o host é libertado para o reboot.

Este procedimento é longo e consome recursos materiais e humanos de forma intensiva. Por isso, deve limitar-se a um número reduzido de máquinas virtuais para respeitar o objetivo de conter a duração da migração.

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 máquina virtual de cada vez, sem se desligar mais do que uma máquina simultaneamente, adiando ao máximo a atualização dos seus hosts. 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.

Máquinas virtuais que não se reiniciam após o reboot do host

O primeiro incidente grave surgiu logo na primeira fase europeia: algumas máquinas virtuais não se reiniciavam após o reboot 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 o reboot sem sincronização do lado da API. A correção aplicada consiste em desativar e ocultar o libvirt-guests.service nos hosts antes do reboot. A partir desta correção, os reinícios automáticos das máquinas virtuais funcionam.

Corrupção de dados em serviços síncronos

Na noite do segundo dia, o sistema de monitorização interno sinalizou dados corrompidos em várias máquinas virtuais distribuídas por 3 clusters. Causa provável: o reboot forçado ocorria a meio da escrita em disco. O graceful shutdown é então prolongado para 60 segundos antes do kill forçado, de modo que as operações de escrita sejam concluídas. É implementado um script de reinício automático das máquinas virtuais que permanecem desligadas.

Deadlock de API em Paris

Na noite entre o segundo e o terceiro dia, as API Nova e Neutron em Paris entram em deadlock mútuo: a API Neutron (limitada a 10 processos) fica sobrecarregada com uma rajada de pedidos da Nova, devolvendo erros 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 aguarda a estabilização.

Saturação do suporte em BHS

No polo de BHS (Canadá), o tráfego API atinge 10 vezes o tráfego máximo habitual, saturando o Manager e o suporte. Alguns clientes descobriram o impacto antes de receberem a comunicação. Este caso ilustra as reações em cadeia no seio da infraestrutura.

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

Os reboots e as intervenções físicas

Um reboot de dezenas de milhares de máquinas implica igualmente uma dimensão física. Há uma taxa de avaria inerente a qualquer reboot de servidor. Na primeira noite, cerca de 20 a 30 hosts dos 6000 não voltaram a funcionar por si próprios: módulos de memória com falhas, configuração da BIOS, interface de rede inativa. Nos Estados Unidos, vários hosts necessitaram de uma remoção da bateria CMOS e de uma drenagem da alimentação antes do repower — um padrão de comportamento recorrente.

Cada polo dispõe de técnicos de datacenter mobilizados como reforço durante a campanha. O seu papel:

• intervir com urgência nos hosts com falha de reboot sinalizados pelos orquestradores;
• substituir as peças defeituosas (discos, módulos de memória, fontes de alimentação);
• efetuar as tarefas manuais que nenhuma ferramenta pode automatizar: hard reboot físico, verificação das luzes indicadoras, intervenção nos racks.

Os técnicos de datacenter operam em modo de intervenção prioritária nos hosts com falha, em coordenação com as equipas de Run/SRE, que estabelecem prioridades de acordo com a exposição do cliente do host. Um host que suporte instâncias críticas e que não recupere tem prioridade sobre um host vazio. Esta priorização cruzada — de software e física — é o que mantém o ritmo da operação.

Comunicação e suporte: informar os clientes afetados

Não é concebível um patching unilateral de impacto controlado sem um esforço de comunicação proporcional.

Uma comunicação direcionada e progressiva

Perante a dinâmica do «follow the sun», não teria feito qualquer sentido uma comunicação global e indiferenciada. A estratégia adotada foi uma comunicação direcionada e progressiva: dirigida apenas aos clientes cujas instâncias estão alojadas nos hosts programados para reboot, e acionada em função do avanço da operação, região a região, fase a fase.

Inicialmente, é tomada a decisão de não ativar uma status-page pública, para não se expor a sequência de implementação. As informações são transmitidas através de comunicações direcionadas no nosso portal de Suporte, com o envio de e-mails aos clientes com os níveis 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 regiões de elevado volume, como GRA6 (quase 90 000 clientes não contactados), é descartado o envio maciço de e-mails para evitar a multiplicação de pedidos de suporte.

Assim, no segundo dia decidiu-se uma mudança de rumo: implementar um banner condicional no Manager através de um feature flipping — se o utilizador conectado constar da lista de contas de clientes (NIC) afetadas, é exibida uma mensagem de informação. O desenvolvimento é realizado durante o dia e a faixa é implementada no terceiro dia. Nesse momento é igualmente criada uma status-page Public Cloud.Apesar destes dispositivos, algumas mensagens não chegam aos destinatários: endereços de contacto obsoletos, notificações filtradas, desfasamento entre a hora prevista do reboot e a hora de envio. Certos 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 recurso

Para os clientes não informados ou em busca de 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 host, tratamento acelerado dos tickets relacionados com a campanha através de um circuito dedicado.O suporte compensa o que as notificações automatizadas não conseguiram transmitir. Não substitui a comunicação, mas compensa algumas das suas lacunas.Cronologia da operação

Le support rattrape ce que les notifications automatisées n’ont pas pu porter. Il ne remplace pas la communication, il en compense certains des manques.

Timeline de l’opération

Perspetivas

A CVE-2026-53359 colocava os nossos clientes e as nossas infraestruturas em risco. O plano de mitigação resultou num impacto no cliente — contido, gradual, 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. Portanto, o objetivo era o menor impacto possível, compatível com a segurança de todo o parque.

A aplicação de patches e o reinício de todos os hosts Public Cloud e VPS nunca tinham sido realizados com esta pressão de tempo. O procedimento de emergência foi implementado tendo em conta o risco associado à vulnerabilidade. Os casos anteriores tinham sido sempre tratados através de um reboot progressivo, tirando partido da taxa de rotação natural das máquinas virtuais na infraestrutura, a par de live migrations ad-hoc planeadas a longo prazo.

As equipas envolvidas nesta operação realizaram um feito notável, com um volume de falhas e de impacto para os clientes muito razoável, tendo em conta a dimensão do projeto. No entanto, conscientes de que os próximos meses poderão dar origem a outras divulgações de vulnerabilidades kernel, parece certo que este procedimento de emergência terá de se repetir. Teremos de fazer melhor da próxima vez, tanto no que diz respeito ao controlo do impacto bruto das reinicializações, como no que se refere à informação prévia aos clientes e ao procedimento de acompanhamento dos clientes afetados durante as operações. Assim, nos dias e semanas que se seguem, vamos identificar os principais impactos nos clientes que sofreram falhas complexas, e trabalhar os problemas encontrados durante as operações internas, através de uma análise pós-incidente, com o objetivo de melhorar os nossos procedimentos no futuro.