Como a KernelCare corrigiu a vulnerabilidade do Januscape antes de a OVHcloud iniciar suas reinicializações em massa

Principais pontos a serem destacados:

• A OVHcloud aplicou a correção no Januscape reiniciando dezenas de milhares de hosts ao longo de 11 dias, o que resultou em tempo de inatividade real, falhas de hardware e a ativação de uma célula de crise global.
• A KernelCare disponibilizou ambas as correções necessárias para o Januscape na forma de patches que não exigem reinicialização, também conhecidos como “patches em tempo real”, com cobertura no feed principal a partir de 7 de julho, antes da primeira onda de reinicializações da OVH em 8 de julho.
• A aplicação de patches com reinicialização deixa todos os hosts vulneráveis até o momento da reinicialização, enquanto a aplicação de patches sem reinicialização elimina a vulnerabilidade no momento em que o patch é aplicado.

A OVHcloud publicou uma das análises pós-incidente mais sinceras sobre infraestrutura que o setor de hospedagem já viu nos últimos anos.

Para corrigir a vulnerabilidade Januscape, registrada como CVE-2026-53359, a empresa aplicou patches e reiniciou dezenas de milhares de hosts KVM que hospedavam cerca de um milhão de máquinas virtuais. A operação se estendeu por todos os continentes, exigiu uma resposta a crises 24 horas por dia, 7 dias por semana, e levou 11 dias para ser concluída.

O site The Register fez uma cobertura da campanha. A análise pós-incidente completa da OVHcloud é uma leitura recomendada para qualquer pessoa responsável por um grande parque de virtualização.

Como caso de sucesso operacional, é realmente impressionante. As equipes da OVHcloud agiram com rapidez, lidaram com falhas sob pressão e documentaram os resultados com uma transparência incomum.

Como questão relacionada à infraestrutura, isso levanta uma questão mais complexa.

Por que a aplicação de uma correção no kernel exigiu uma campanha de reinicialização em massa?

Eis o contraste. Para as plataformas compatíveis com o KernelCare, a correção do Januscape — que não exigia reinicialização — já estava disponível no feed principal de patches antes mesmo de a OVH reiniciar seu primeiro servidor. As frotas assinantes receberam a correção durante um ciclo normal de atualizações. Sem reinicializações. Sem interrupções. Sem campanha.

Januscape em duas frases

Januscape é uma vulnerabilidade do tipo “use-after-free” no código de gerenciamento de memória sombra x86 do KVM. Um invasor com acesso de root dentro de uma máquina virtual convidada poderia explorá-la para causar uma falha no host e, potencialmente, executar código com privilégios no nível do host.

A falha afeta sistemas Intel e AMD e permaneceu no kernel do Linux por cerca de 16 anos. Para corrigi-la, são necessárias duas correções interligadas no código-fonte, associadas aos CVE-2026-53359 e CVE-2026-46113.

Nossa análise técnica do Januscape aborda detalhadamente a vulnerabilidade, a forma de exploração e as correções necessárias.

Também realizamos uma transmissão ao vivo explicando detalhadamente a falha, caso você prefira ouvir dois especialistas discutindo o CVE em vez de ler mais sobre o assunto. .

O artigo que você está lendo neste momento trata do projeto de lei operacional.

O que é necessário para a aplicação de patches que exigem reinicialização

Tudo o que se segue é proveniente da análise pós-incidente da OVH e da matéria do The Register. Nada disso é especulação.

A OVHcloud testou inicialmente seu procedimento de implantação em Sydney. A região oferecia uma área de cobertura relativamente pequena, menor demanda noturna e cobertura durante o horário comercial por equipes na Europa. Após a validação do manual de procedimentos, as reinicializações passaram a ser realizadas em todo o mundo por meio de uma operação do tipo “follow-the-sun”.

Esse processo envolvia muito mais do que instalar um pacote do kernel e reiniciar as máquinas. As ondas de reinicialização eram regidas por limites de interrupção. A OVHcloud suspendia uma onda se 15 hosts estivessem fora do ar simultaneamente em uma região de alta densidade ou se cinco estivessem fora do ar em qualquer outro lugar.

Para projetos de clientes distribuídos por vários hosts, os orquestradores calcularam um gráfico de co-localização. O objetivo era evitar que dois hosts que suportassem o mesmo projeto fossem reiniciados dentro do mesmo intervalo de tempo.

As equipes também mapearam as dependências internas dos serviços antes de cada implantação regional. Algumas máquinas virtuais essenciais tiveram que ser migradas em tempo real primeiro, para que bancos de dados, APIs, sistemas de monitoramento e outros serviços operacionais permanecessem disponíveis durante as reinicializações.

Os clientes cujas instâncias estavam todas hospedadas em um único servidor sofreram uma interrupção. Eles foram informados sobre o período previsto para a intervenção, mas a urgência da medida de segurança fez com que não fosse viável optar por não participar.

Então, o mundo físico entrou em cena. Na primeira noite, cerca de 20 a 30 hosts, de um total de 6.000, não voltaram a funcionar por conta própria: módulos de memória com falha, problemas no BIOS, interfaces de rede inoperantes.

Algumas máquinas nos EUA precisavam que a bateria CMOS fosse removida e que a energia fosse desligada antes de ligarem. Técnicos de data center ficaram de plantão em todos os locais durante todo o período, substituindo peças e realizando trabalhos manuais nos racks que nenhum orquestrador consegue automatizar.

O software também apresentou problemas. As máquinas virtuais não conseguiam reiniciar após a reinicialização do host, até que um conflito no libvirt-guests foi identificado e contornado. Desligamentos forçados corromperam dados nas máquinas virtuais em três clusters. As APIs do OpenStack de Paris entraram em impasse, gerando erros HTTP 503 por duas horas, adiando uma onda de tráfego. No local canadense, o tráfego atingiu 10 vezes o pico normal e sobrecarregou a equipe de suporte.

É preciso dar crédito a quem merece: a equipe de crise da OVH conduziu tudo muito bem, e divulgar as falhas exige mais coragem do que a maioria dos fornecedores tem.

A execução não foi o problema. O problema é o modelo de correção que exigiu isso.

O que os sistemas protegidos pelo KernelCare fizeram, em vez disso

As frotas que utilizam o KernelCare lidaram com a mesma vulnerabilidade sem recorrer a nenhum dos mecanismos operacionais descritos acima. Sem ondas de reinicialização, sem janelas de manutenção, sem equipes de técnicos mobilizadas.

O objetivo atual da TuxCare em relação a escaladas de privilégios locais e vulnerabilidades de dia zero é disponibilizar patches em tempo real dentro de 48 horas após a divulgação pública. Neste caso, o prazo foi menor: o embargo foi suspenso em 6 de julho, e a KernelCare começou a disponibilizar as duas correções necessárias juntas por meio de seu processo normal de aplicação de patches sem reinicialização, às vezes chamado de “patch em tempo real”, em 7 de julho (aproximadamente 24 horas depois).

Conforme documentado em nossa análise técnica do Januscape, a cobertura disponível ao público em 7 de julho incluía:

• A família Enterprise Linux 10
• Ubuntu 22.04, incluindo as versões para nuvem
• Debian 13
• Sistemas Ubuntu Focal que utilizam o kernel Jammy para suporte a hardware
• Proxmox VE 7 e 8

Outras famílias de kernels passaram pelas fases de desenvolvimento, testes e, posteriormente, pela implantação gradual.

A OVHcloud deu início às primeiras etapas de reinicialização em Sydney no dia seguinte, 8 de julho.

Assim, enquanto um grupo de operadores ainda estava programando o tempo de inatividade, as frotas atualizadas já estavam protegidas — com a ressalva de sempre de que isso não prova que as atualizações de 7 de julho seriam aplicáveis aos próprios kernels Debian de produção da OVHcloud. A OVHcloud não divulgou publicamente informações suficientes sobre as versões para que isso pudesse ser comprovado.

Isso demonstra a alternativa operacional disponível para provedores de hospedagem que utilizam kernels compatíveis.

Quando o patch aplicável, que não exigia reinicialização, chegava ao sistema, o código vulnerável podia ser substituído sem reiniciar o host. Não havia janela de reinicialização a ser programada, não era necessário organizar as cargas de trabalho dos clientes em torno de um ciclo de reinicialização e não era necessário enviar nenhum aviso aos clientes relacionado à reinicialização.

Também não havia problemas ocultos de hardware prestes a surgir durante uma reinicialização de emergência.

Os administradores poderiam verificar a cobertura diretamente:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

A diferença não é que um grupo tenha levado o Januscape a sério e o outro não. Ambos o levaram a sério.

A abordagem da OVH transformou a correção em um grande evento de infraestrutura, enquanto a aplicação de patches sem reinicialização com o KernelCare teria tornado isso uma implantação rotineira de patches.

A janela de exposição é o custo oculto

A instalação de um pacote de kernel corrigido não protege o kernel que está em execução no momento. A vulnerabilidade permanece ativa até que o computador seja reiniciado com a versão atualizada.

Isso cria uma janela de exposição em todos os hosts que ainda estão aguardando sua vez.

A OVHcloud reconheceu explicitamente esse problema. Lidar com os clientes individualmente teria prolongado a campanha e deixado grande parte da frota vulnerável por semanas. A empresa também limitou a comunicação pública enquanto a implementação estava em andamento, pois temia que os clientes pudessem testar a vulnerabilidade de travamento disponível publicamente na infraestrutura de produção.

Com a aplicação de patches sem reinicialização, a janela é fechada assim que o patch aplicável é instalado com sucesso. A atualização convencional do kernel e a reinicialização podem, então, ocorrer posteriormente, durante um ciclo de manutenção planejado, em vez de no meio de uma emergência de segurança.

A aplicação de patches sem reinicialização é muito instável?

A OVHcloud avaliou a aplicação de patches sem interrupção e rejeitou essa opção. Sua análise pós-incidente argumenta que modificar um kernel em execução pode reduzir o fortalecimento da segurança e criar a possibilidade de instabilidade em toda a frota.

Essa preocupação merece uma resposta direta. Vamos analisar a questão sob três perspectivas:

Primeiro, como esses patches são efetivamente distribuídos. Cada patch do KernelCare é compilado e testado em relação à versão específica do kernel a que se destina; em seguida, passa por uma validação interna e por uma série de testes em etapas antes de chegar ao canal de produção. As frotas que desejam uma etapa adicional de verificação utilizam o KernelCare ePortal e definem suas próprias etapas de aprovação e políticas de implantação. Trata-se de um pipeline de entrega maduro.

Em segundo lugar, esse bug específico. A correção do Januscape é um exemplo clássico de patch que pode ser aplicado sem reinicialização: uma correção isolada na rota de falha da MMU do KVM, sem estado persistente a ser migrado e sem estruturas de dados a serem transformadas. Se você estivesse criando um CVE para demonstrar para que serve a aplicação de patches sem reinicialização, seria exatamente assim.

Em terceiro lugar, e essa é a parte que vale a pena analisar com atenção: a própria análise pós-incidente da OVH documenta a instabilidade do processo de reinicialização. Dezenas de hosts que nunca voltaram a funcionar. Discos corrompidos devido a desligamentos forçados. Um impasse na API regional. Máquinas virtuais (VMs) ficando offline devido a um conflito de serviços. A escolha nunca foi entre um patch sem reinicialização, que apresentava riscos, e uma reinicialização sem riscos. Era entre dois métodos com perfis de risco diferentes e, em escala de frota, os riscos do caminho de reinicialização são grandes, concretos e documentados. A estabilidade é uma propriedade de todo o caminho de correção, não do mecanismo de aplicação de patches isoladamente.

Se sua frota puder ser totalmente reiniciada em até 24 horas sem impacto para os clientes, a equação pode realmente ser diferente para você. Se uma vulnerabilidade (CVE) no kernel implicar em uma campanha de várias semanas, uma célula de crise e técnicos em todos os data centers, o problema está no modelo, e não na sua equipe.

Campanha de reinicialização versus aplicação de patches sem reinicialização

Isso provavelmente vai acontecer de novo

O Januscape não foi um evento isolado.

O CopyFail, o DirtyFrag, o GhostLock e outras vulnerabilidades graves do kernel forçaram as equipes de infraestrutura a tomar decisões urgentes sobre exposição, tempo de inatividade e correção.

O CISO da OVHcloud reconheceu que novas vulnerabilidades no kernel poderiam exigir que o procedimento de emergência fosse repetido. A tarefa imediata da empresa é tornar esse procedimento mais seguro e previsível na próxima vez.

Outros provedores de hospedagem oferecem outra opção.

Elas podem reduzir, desde o início, a frequência com que uma vulnerabilidade do kernel se transforma em um incidente na infraestrutura que afeta os clientes.

A OVHcloud demonstrou como é possível conduzir com sucesso uma campanha de reinicialização em grande escala mesmo sob pressão. A KernelCare demonstrou que, para os sistemas compatíveis, a mesma vulnerabilidade poderia ser removida de um kernel em execução sem a necessidade de iniciar essa campanha.

A lição duradoura do caso Januscape não é que os provedores de hospedagem precisem de um manual de procedimentos de reinicialização mais eficaz.

O que importa é que eles não precisem ativar uma a cada vez que surgir uma vulnerabilidade crítica no kernel.

Obtenha atualizações sem reinicialização com o KernelCare →