Administradores que utilizam o Veeam Software Appliance precisam ficar atentos a um problema de inicialização que afeta máquinas virtuais executadas em determinados servidores com processadores AMD EPYC. A Veeam confirmou ocorrências de kernel panic durante o boot do sistema, impedindo que o appliance Linux conclua sua inicialização.
A falha está relacionada ao mecanismo jitterentropy, responsável por fornecer entropia ao kernel Linux para operações criptográficas. Em ambientes que utilizam configurações de segurança compatíveis com FIPS, uma verificação de integridade pode apresentar resultados inconsistentes em determinados processadores AMD, provocando a interrupção do sistema.
O problema foi identificado nos modelos AMD EPYC 7262, 7302 e 7F72, pertencentes à família EPYC 7002. Além de explicar a origem da falha e as medidas de contingência, o alerta merece atenção porque a Veeam também disponibilizou uma atualização de segurança para corrigir uma vulnerabilidade crítica no kernel Linux, identificada como CVE-2026-98432.
O que provoca o kernel panic durante a inicialização do appliance Linux da Veeam
A falha acontece durante o processo de inicialização do Linux. Nesse momento, o kernel carrega seus componentes e executa verificações de segurança necessárias para permitir o funcionamento dos mecanismos criptográficos.
Um desses componentes é o jitterentropy, que utiliza pequenas variações temporais do funcionamento do hardware para coletar informações de entropia. Esses dados contribuem para a geração de números aleatórios utilizados em operações como criação de chaves criptográficas e inicialização de mecanismos de segurança.
Em sistemas configurados para atender aos requisitos FIPS, os mecanismos de geração de números aleatórios precisam passar por verificações específicas. Essas verificações ajudam a identificar fontes de entropia que não atendem aos requisitos de funcionamento esperados.
No cenário identificado pela Veeam, determinadas CPUs AMD EPYC apresentam resultados inconsistentes durante os testes de integridade do jitterentropy. Quando a verificação falha, o kernel interrompe a inicialização para evitar que o sistema continue operando com um mecanismo de entropia considerado inadequado.
O erro apresentado no console da máquina virtual é:
Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9
A mensagem indica que a inicialização do jitterentropy falhou porque o ambiente hospedeiro não atendeu aos requisitos esperados pelo mecanismo.
Um aspecto importante é que a ocorrência não é necessariamente reproduzida em todas as inicializações. A máquina virtual pode funcionar normalmente durante determinado período e apresentar o problema depois de uma atualização ou reinicialização posterior.
Essa característica intermitente dificulta o diagnóstico, principalmente em ambientes nos quais os administradores não acompanham diretamente o console das máquinas virtuais.
Também é importante destacar que o problema não significa, por si só, que os repositórios de backup foram corrompidos ou que os dados armazenados foram perdidos. A interrupção acontece durante o boot, antes que o sistema operacional consiga disponibilizar normalmente seus serviços.

Quais processadores AMD EPYC apresentam o problema
A Veeam identificou ocorrências envolvendo três modelos de processadores da família AMD EPYC 7002, baseada na arquitetura Zen 2:
- AMD EPYC 7262;
- AMD EPYC 7302;
- AMD EPYC 7F72.
O alerta contempla o Veeam Software Appliance 13.1 e versões posteriores.
O cenário exige atenção porque o problema aparece dentro do sistema operacional convidado, embora esteja relacionado ao comportamento observado no ambiente de hardware hospedeiro.
Na prática, administradores que executam o appliance Linux em plataformas de virtualização precisam identificar quais servidores físicos utilizam esses processadores. A simples verificação da versão do sistema de backup não é suficiente para determinar a exposição.
Outro detalhe relevante é que a falha não representa necessariamente um defeito físico no processador. O problema está relacionado à interação entre o hardware, o mecanismo de coleta de entropia e as verificações de conformidade executadas pelo kernel Linux.
Como recuperar uma máquina virtual afetada pela falha de inicialização
A Veeam recomenda medidas de contingência para reduzir o impacto do problema enquanto não existe uma correção definitiva para a falha de jitterentropy.
A primeira possibilidade é migrar a máquina virtual para um servidor equipado com outro modelo de processador. Quando a infraestrutura permite, essa alternativa reduz a exposição ao comportamento identificado nos processadores AMD EPYC mencionados no alerta.
Entretanto, nem todas as organizações conseguem realizar essa movimentação imediatamente. Por isso, existem outras medidas operacionais.
Desligamento completo em vez de reinicialização
Uma das orientações mais importantes é utilizar um ciclo completo de energia quando a máquina virtual apresentar o kernel panic.
Uma reinicialização convencional, conhecida como warm reboot, não resolve necessariamente a condição que provoca a falha.
O procedimento recomendado é realizar um cold power cycle, desligando completamente a máquina virtual pelo gerenciamento do hipervisor e ligando-a novamente depois que o desligamento estiver concluído.
Essa distinção é importante porque uma reinicialização do sistema operacional não representa necessariamente uma interrupção completa da execução da máquina virtual.
Controle das atualizações automáticas
Outra medida recomendada é desabilitar temporariamente as atualizações automáticas enquanto a equipe organiza o gerenciamento das manutenções.
A intenção é impedir que atualizações sejam instaladas sem acompanhamento em ambientes que podem apresentar dificuldades durante a inicialização.
Os administradores devem programar a instalação manual dos pacotes em janelas de manutenção supervisionadas, mantendo acesso ao console da plataforma de virtualização.
Monitoramento depois da recuperação
Depois que o sistema consegue inicializar corretamente, a Veeam informa que o funcionamento normal dos serviços não deve ser afetado pela falha de jitterentropy.
Mesmo assim, é necessário verificar os serviços de backup, a comunicação com os repositórios, os agendamentos e as tarefas que eventualmente tenham sido interrompidas durante a indisponibilidade.
Vulnerabilidade CVE-2026-98432 exige atualização do kernel Linux
Além do problema de inicialização, administradores precisam acompanhar outra ocorrência de segurança envolvendo o kernel Linux utilizado nos produtos da Veeam.
A empresa disponibilizou uma correção para a CVE-2026-98432, vulnerabilidade crítica associada ao processamento de conexões TCP e ao código de rede IPv4, com impacto também no cenário de Multipath TCP (MPTCP).
A falha está relacionada a uma condição de use-after-free. Esse tipo de vulnerabilidade acontece quando um componente continua acessando uma região de memória depois que ela foi liberada, podendo provocar corrupção de memória e comprometer a estabilidade e a segurança do sistema.
A exploração pode permitir execução remota de código em determinadas condições, tornando a vulnerabilidade especialmente preocupante para servidores expostos a redes não confiáveis.
A Veeam disponibilizou uma atualização corretiva pelo seu mecanismo de distribuição de pacotes. O kernel corrigido é identificado pela seguinte versão:
5.14.0-570.60.1+27.2.el9_6_ciq
A atualização é distribuída pelo Veeam Updater, que verifica a disponibilidade de pacotes periodicamente. Na configuração padrão, as atualizações obrigatórias são instaladas automaticamente no domingo seguinte, às 14h, considerando o fuso horário configurado no servidor.
Também é possível iniciar a atualização manualmente pelo console Veeam Host Management, sem depender do próximo ciclo automático.
Existe, porém, um desafio operacional: a instalação do novo kernel exige uma reinicialização. Nos servidores AMD EPYC afetados, justamente esse procedimento pode desencadear o erro de jitterentropy.
Por isso, as equipes precisam planejar a aplicação da correção de segurança com acompanhamento presencial ou remoto, acesso ao console do hipervisor e possibilidade de executar um desligamento completo caso a máquina virtual não consiga inicializar.
Desabilitar temporariamente as atualizações automáticas não significa ignorar a CVE-2026-98432. A correção deve continuar no planejamento de manutenção, com prioridade compatível com a gravidade da vulnerabilidade e a exposição do ambiente.
Como proteger a infraestrutura de backup contra novas interrupções
Os dois problemas exigem abordagens diferentes. A falha de jitterentropy compromete a inicialização em determinados ambientes AMD EPYC, enquanto a CVE-2026-98432 exige a aplicação de uma atualização de segurança no kernel Linux.
Para administradores, o primeiro passo é identificar os servidores físicos que utilizam os processadores afetados e verificar quais máquinas virtuais executam o Veeam Software Appliance 13.1 ou posterior.
Também é recomendável revisar a política de atualizações, organizar janelas de manutenção supervisionadas e documentar o procedimento de recuperação por desligamento completo.
Outro cuidado essencial é verificar se existem cópias de segurança independentes e procedimentos de restauração testados. Uma plataforma de backup temporariamente indisponível pode comprometer os objetivos de recuperação de uma organização, mesmo quando os dados armazenados permanecem intactos.
O alerta reforça a importância de considerar a compatibilidade entre hardware, kernel Linux e mecanismos de segurança antes de executar atualizações em ambientes de missão crítica.
