Januscape CVE-2026-53359: Fuga do ambiente convidado via KVM

Vá direto para um resumo gerado por IA desta postagem do blog

A versão resumida

O que é: Januscape (CVE-2026-53359) é uma vulnerabilidade do tipo “use-after-free” na MMU sombra KVM/x86 do kernel do Linux. Um sistema convidado malicioso pode fazer com que o KVM reutilize uma página sombra armazenada em cache que não corresponde mais ao mapeamento que está sendo construído, o que deixa uma entrada obsoleta no mapeamento reverso apontando para uma área de memória que o KVM liberará posteriormente. Ir para a versão completa →

Impacto: O resultado público e confiável é uma falha no host. Pesquisas públicas descrevem uma fuga completa do guest para o host – código dentro de um guest malicioso sendo executado no host como root. Confirmamos de forma independente a corrupção da memória do host e a primitiva de negação de serviço no AlmaLinux 9 e no Ubuntu 24.04, embora não tenhamos reproduzido a cadeia completa de fuga. Em sistemas da família RHEL onde /dev/kvm é acessível a todos, o mesmo bug permite a escalada de privilégios local até o root. Ir para a versão completa →

Status: Corrigido no código-fonte original (commit 81ccda30b4e8, incorporado ao código principal em junho de 2026). O NVD publicou o CVE em 4 de julho de 2026, e o embargo foi suspenso em 6 de julho. Tratava-se de uma submissão “zero-day” ao kvmCTF; para os defensores atualmente, é um “N-day” com uma prova de conceito pública. Ir para a versão completa →

Gravidade: A NVD não havia atribuído uma pontuação CVSS até o momento da publicação. A ausência da pontuação não indica baixo impacto. Classifique-a internamente como alta e não espere por uma caixa colorida. Ir para a versão completa →

Quem é afetado: hosts KVM/x86, Intel e AMD, que disponibilizam virtualização aninhada para os sistemas convidados. A rota de fuga requer um elemento além dos privilégios de root do sistema convidado: a virtualização aninhada. Ir para a versão completa →

Vulnerabilidade relacionada: o Januscape precisa de uma segunda correção, CVE-2026-46113, para ser totalmente corrigido. A aplicação da correção apenas para a vulnerabilidade anterior não impede o funcionamento do Januscape. Ir para a versão completa →

Faça isso agora: aplique uma correção nos hosts KVM afetados usando um kernel corrigido ou um patch que não exija reinicialização. Os hosts que não executam máquinas virtuais podem descarregar e bloquear os módulos do KVM. Os hosts que executam máquinas virtuais, mas não precisam de virtualização aninhada, devem desativá-la, o que remove a rota de fuga do “untrusted-guest”. Os hosts que precisam de ambas as funcionalidades não podem ser corrigidos apenas por meio da configuração. Ir para a versão completa →

Precisa aplicar patches em hosts KVM sem reiniciar todas as VMs?

O KernelCare aplica patches de segurança do kernel do Linux sem tempo de inatividade, interrupção da carga de trabalho ou janelas de manutenção de emergência.
Status do KernelCare: A partir de 7 de julho de 2026, patches que não exigem reinicialização, abrangendo tanto o CVE-2026-53359 quanto seu complemento obrigatório, o CVE-2026-46113, estão sendo disponibilizados em conjunto para várias famílias de kernel, com mais versões em desenvolvimento ativo. O status completo da versão e as K-tags estão listados abaixo.

Baixe o KernelCare →

A versão completa

O Januscape põe em causa a promessa central da virtualização.

Uma VM convidada pode estar comprometida, sob controle do cliente, obsoleta, intencionalmente hostil ou simplesmente mal configurada. Nenhuma dessas situações deve permitir que ela acesse a memória pertencente ao host. A função do KVM é traduzir a memória da VM convidada com segurança, mantendo essa separação. O Januscape rompe a lógica de gerenciamento por trás dessa tradução.

O bug está localizado em arch/x86/kvm/mmu/mmu.c, na MMU sombra do KVM. Esse código mantém as estruturas da tabela de páginas do lado do host que mapeiam os endereços usados por um convidado para a memória autorizada pelo host. Sob uma sequência controlada de alterações no mapeamento do convidado, o KVM reutiliza uma página-sombra existente, mesmo que sua função registrada não corresponda mais ao mapeamento que está sendo construído. Essa reutilização deixa uma entrada de mapeamento reverso apontando para uma estrutura que o KVM libera posteriormente, e uma varredura subsequente do mapeamento reverso desreferencia a página liberada.

Um ponto a ser destacado logo de início, pois determina quem fica exposto. Não se trata de uma disputa de dados no sentido clássico, e não é o mesmo defeito que o de seu “irmão”. O kernel classifica o Januscape como um “use-after-free” causado por uma função inesperada da página-sombra. O gatilho envolve a alteração de um mapeamento de convidado de forma assíncrona, de fora do próprio percurso de páginas do convidado; portanto, atingir a janela exige precisão de tempo. Mas a causa raiz é a falta de uma comparação, não um bug de bloqueio. É importante manter essa distinção, pois a correção e as medidas de mitigação decorrem dela.

Como funciona o Januscape

Em linhas gerais:

[Guest with root + nested virtualization exposed]
│  forces KVM back through the legacy shadow MMU
▼
[Guest creates a large 2 MB mapping → KVM builds a direct shadow page]
│
▼
[Guest rewrites the mapping to a 4 KB page-table path]
│  new mapping needs a non-direct (direct=0) page
▼
[kvm_mmu_get_child_sp() reuses the old direct page – gfn matches, role NOT compared]
│
▼
[Cleanup computes the wrong frame number → reverse-map entry not removed]
│
▼
[Shadow page freed; stale reverse-map entry left behind]
│  later rmap walk (dirty logging / MMU-notifier invalidation)
▼
[Use-after-free write of a fixed marker into freed memory]
▼
[Host crash (public PoC)  →  or guest-to-host escape, root on host (withheld exploit)]

Analisando esse processo em detalhes: a sequência começa com uma entrada no diretório de páginas do convidado que descreve um grande mapeamento de 2 MB. O KVM cria uma página `kvm_mmu_page` que abrange 512 entradas individuais de 4 KB e, como o mapeamento do convidado é uma página grande contígua, marca a página-sombra como direta.

O mapeamento é então alterado fora do fluxo normal de execução do convidado. Em vez de uma página grande, a mesma entrada do diretório de páginas agora aponta para outra tabela de páginas que contém mapeamentos individuais de 4 KB. O KVM precisa de um tipo diferente de página-sombra para essa estrutura: a original tem um papel direto, enquanto o novo mapeamento requer um papel não direto. O caminho vulnerável `kvm_mmu_get_child_sp()` não compara esse papel completo antes de decidir reutilizar a página existente. O número do quadro coincide, portanto a página é aceita, e o KVM instala uma nova entrada de folha e registra uma entrada de mapeamento reverso para o quadro resolvido por meio da nova percorrida.

O problema vem à tona durante a limpeza. Como a página-pai reutilizada ainda afirma ser direta, o KVM calcula o quadro para a nova entrada de 4 KB como sp->gfn + índice, em vez de usar a tradução armazenada na página-sombra. Em seguida, ele procura a entrada do mapa reverso sob o número de quadro incorreto e não consegue removê-la. A página-sombra é liberada, e a entrada obsoleta do mapa reverso permanece no sistema. Qualquer operação posterior que percorra esse mapa reverso desreferencia uma entrada dentro da página liberada. O kernel registra o registro de alterações (dirty logging) e a invalidação do notificador MMU como as operações que causam isso.

Há um detalhe que explica tanto a demonstração de conceito (PoC) pública quanto a exploração que não foi divulgada. Durante a desmontagem, o KVM grava uma constante de marcador fixa naquilo que agora pode ser memória realocada. Trata-se de uma verdadeira gravação do tipo “use-after-free”, mas restrita: um valor fixo em um endereço que o invasor precisa alinhar com um objeto útil do kernel. É difícil garantir esse alinhamento de forma confiável, e é por isso que o código público se limita a causar uma falha no host e a fuga completa não foi divulgada.

O sistema convidado acessa esse código por meio da virtualização aninhada. Em um host moderno que executa sistemas convidados com paginação de hardware (EPT na Intel, NPT na AMD), a MMU-sombra de software normalmente não é acionada. A exposição da virtualização aninhada é o que força o KVM a recorrer à MMU-sombra legada, que é onde o Januscape se situa. Essa é a razão pela qual um host pode parecer moderno e ainda assim estar totalmente dentro do escopo.

O que confirmamos

Nossos testes confirmaram que a vulnerabilidade pode ser explorada tanto no kernel do Enterprise Linux quanto no Ubuntu 24.04. Reproduzimos o ataque DoS contra o host e a corrupção de memória. Não executamos a fuga de ponta a ponta, que é a exploração que o pesquisador optou por não divulgar.

No AlmaLinux 9 com o kernel 5.14.0-687.5.3.el9_8, o gatilho causou um erro fatal (BUG) no kernel na função pte_list_remove(). O host entrou em pânico em um intervalo de segundos a minutos, enquanto o processo ativo era o qemu-kvm. Trata-se de uma negação de serviço no host, desencadeada de forma confiável pelo sistema convidado, no kernel testado.

No Ubuntu 24.04 com o kernel 6.8.0-111-generic, a mesma corrupção gerou um aviso em vez de um panic imediato. O kernel relatou uma incompatibilidade de GFN na função `kvm_mmu_page_set_translation()` — tornando visível a confusão de quadros, que era a causa raiz —, seguida por um aviso na função `pte_list_remove()`. O host sobreviveu porque essas verificações de consistência são classificadas como avisos nesta versão do Ubuntu, em vez de verificações fatais de erros (BUG), de modo que ele continuou em execução com um estado corrompido da MMU-sombra (Tainted: G W).

Um aviso que não é ignorado não significa segurança. Isso significa que o estado da tradução gerenciado pelo host ficou inconsistente e que a máquina conseguiu passar, com dificuldade, por sua própria verificação. Para a coleta controlada de dumps de falha, você pode tornar as reproduções da classe de aviso fatais:

sudo sysctl kernel.panic_on_warn=1

Trata-se de um recurso de teste e de assistência ao vmcore. Não é uma medida de mitigação.

O que a correção do Upstream altera

A correção adiciona a verificação de função que faltava antes que o KVM reutilize uma página sombra. Antes do patch, bastava que o número do quadro do convidado correspondesse para que uma página existente fosse aceita. Após a aplicação, a função `kvm_mmu_get_child_sp()` compara a função completa da página (role.word) com o número do quadro e reutiliza uma página somente quando ambos coincidem. Quando a função é incompatível, o KVM elimina a entrada existente e cria a página-sombra correta, em vez de manter uma interpretação desatualizada. Os mantenedores do KVM, Paolo Bonzini e Sean Christopherson, escreveram o patch.

Conceitualmente:

Before:  matching gfn → reuse shadow page → role mismatch ignored → stale reverse map → use-after-free
After:   matching gfn → compare role.word → reject incompatible page → zap old entry → build correct page

A correção do Januscape no código-fonte original é o commit 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb. Sua correção associada, a do CVE-2026-46113, é o commit 0cb2af2ea66ad8ff195c156ea690f11216285bdf. Cada uma corrige uma condição diferente de “stale-shadow-page”, portanto ambas devem estar presentes em um kernel corrigido.

Os registros dos fornecedores e do “rebootless-patch” nem sempre os identificam separadamente. Algumas versões anteriores do KernelCare incluíam a correção da vulnerabilidade “Januscape” como um componente complementar sem CVE sob o código CVE-2026-46113; portanto, a ausência de uma sequência de caracteres distinta para CVE-2026-53359 não significa, por si só, que a correção da vulnerabilidade esteja faltando.

The Sibling: CVE-2026-46113

A vulnerabilidade Januscape não surgiu isoladamente. Antes de ser corrigida, os desenvolvedores do kernel fecharam a CVE-2026-46113, outra vulnerabilidade do tipo “use-after-free” no shadow-paging do KVM/x86 na mesma parte da MMU. As duas falhas devem ser discutidas em conjunto, mas nunca confundidas, pois as duas correções abordam vulnerabilidades diferentes e um host precisa de ambas.

A vulnerabilidade CVE-2026-46113 ocorre quando o KVM reutiliza uma página-sombra criada para o número incorreto de quadro do convidado. Um mapeamento do convidado é alterado entre entradas da VM; o KVM continua usando uma página-sombra criada para o mapeamento original, e uma nova entrada da tabela de páginas é registrada em um quadro fora do intervalo que o KVM pesquisa posteriormente durante a limpeza. A limpeza não a detecta. A página-sombra é liberada. A entrada obsoleta do mapeamento reverso permanece. Uma varredura posterior do mapeamento reverso desreferencia a página liberada.

A correção do CVE-2026-46113, commit 0cb2af2ea66a, adicionou uma verificação do número do quadro do convidado: quando o KVM detecta que uma página existente pertence ao quadro errado, ele apaga a entrada antiga em vez de reutilizá-la. O Januscape demonstrou que essa verificação não era suficiente.

No caminho do Januscape, o número do quadro pode parecer correto. A discrepância está na função da página de sombra:

O mapeamento original cria uma página de sombra direta para um mapeamento grande de 2 MB (direct=1).
O convidado altera esse mapeamento para que ele aponte para uma tabela de páginas de nível inferior.
O novo caminho requer uma página de sombra não direta para mapeamentos de 4 KB (direto=0).
O KVM encontra um número de quadro correspondente e reutiliza a página antiga.
O quadro bate, mas a interpretação da página não.

O CVE-2026-46113 corrigiu o caso do quadro incorreto. O Januscape corrigiu o caso da função incorreta. A correção anterior é apenas o contexto; o Januscape é a vulnerabilidade sobre a qual trata este artigo. A aplicação apenas do patch anterior não corrige o Januscape.

Quem é afetado

O Januscape afeta sistemas Linux que utilizam a MMU sombra KVM/x86. Isso inclui hosts Intel e AMD, pois o código vulnerável está localizado na lógica compartilhada da MMU KVM/x86, e não apenas no kvm_intel ou no kvm_amd. O pesquisador demonstrou o mesmo gatilho em ambos, alterando apenas os bits da tabela de páginas específicos da arquitetura. Várias diferenças determinam o grau de exposição de um determinado host.

Hipervisores KVM executando máquinas convidadas com virtualização aninhada. Prioridade máxima. Uma máquina convidada maliciosa ou comprometida, com privilégios de root em sua própria VM, pode acessar o caminho vulnerável do kernel do host por meio da virtualização aninhada. Esse é o cenário de fuga da máquina convidada para o host, e é nele que uma única instância alugada pode causar a falha do host físico ou, com a exploração não divulgada, assumir o controle de máquinas convidadas co-localizadas. Em nosso laboratório, a reprodução da máquina virtual carregou um módulo que controla o estado bruto do VMX/SVM, que é exatamente o caminho da virtualização aninhada.

Hosts KVM que executam máquinas virtuais, mas não expõem a virtualização aninhada. Menor exposição ao vetor “máquina virtual para host”, pois a MMU de sombra do software não é forçada a entrar em ação para essas máquinas virtuais. Confirme se a virtualização aninhada está realmente desativada antes de confiar nisso.

Hosts com KVM disponível, mas sem máquinas virtuais em execução. Esses hosts ainda podem expor um caminho local caso um usuário local não confiável consiga abrir o arquivo /dev/kvm e controlar o KVM diretamente. Se o KVM não estiver sendo utilizado, descarregue e bloqueie os módulos.

Contêineres e CloudLinux LVE. Um contêiner normal não possui acesso automático ao KVM. Os ambientes de contêiner e LVE não são vulneráveis simplesmente por compartilharem o kernel do host. A vulnerabilidade depende da capacidade do contêiner de acessar o /dev/kvm, controlar o QEMU ou utilizar virtualização aninhada. Não testamos esses ambientes e não os consideramos seguros por padrão. Verifique a configuração real do dispositivo e dos privilégios.

Versões do kernel empresarial. Não determine a vulnerabilidade com base apenas no comando `uname -r`. As distribuições empresariais fazem o backport de alterações do KVM para versões anteriores; portanto, um kernel EL9 baseado na versão 5.14 contém a lógica MMU afetada, enquanto um kernel numericamente mais recente pode já incluir um backport direcionado. Confirme a correção do fornecedor, a cobertura do KernelCare ou o padrão do código-fonte para identificar exatamente qual kernel está em execução.

A armadilha da versão, neste caso, funciona de maneira oposta à habitual. Não é “nosso kernel é muito antigo”. É “nosso hardware é muito novo”. Um host em EPT ou NPT parece moderno e seguro até o momento em que expõe a virtualização aninhada e, discretamente, redireciona os convidados de volta por meio de um código de shadow-MMU com 16 anos de idade. Faça sua avaliação com base no que o host expõe, e não no silício em que ele roda.

Verifique a superfície de ataque do KVM

Verifique se os módulos KVM estão carregados:

lsmod | grep -E '^kvm|kvm_(intel|amd)'

Verifique se o dispositivo KVM existe e quem tem acesso a ele:

ls -l /dev/kvm

Verifique se há cargas de trabalho ativas do QEMU/KVM:

pgrep -a -f 'qemu-system|qemu-kvm'

Verifique se a virtualização aninhada está ativada:

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested      # AMD

Para hosts gerenciados pelo libvirt:

virsh list --all

Esses comandos informam se o KVM está exposto, em uso e se está expondo virtualização aninhada. Eles não comprovam se o Januscape está atualizado.

Aja agora para mitigar

Existem medidas de mitigação de configuração reais aqui, e cada uma delas bloqueia um vetor específico. Nenhuma delas bloqueia todos os vetores, e é exatamente esse o objetivo.

Hosts que não executam máquinas virtuais. Se o sistema não precisar do KVM, descarregue os módulos e impeça que sejam carregados. Use o comando `install … /bin/false` em vez de uma simples linha no `blacklist`, pois o `blacklist` por si só não impede um carregamento explícito ou motivado por dependências.

# unload now (fails if a VM is running, in which case this host isn't a candidate)
sudo modprobe -r kvm_intel kvm      # kvm_amd on AMD hardware

# prevent load on boot
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf

Verifique se o comando `lsmod | grep kvm` não retorna nenhum resultado e se o comando `ls /dev/kvm` informa que não existe tal arquivo. Para reverter, exclua o arquivo `/etc/modprobe.d/disable-kvm.conf` e execute o comando `modprobe kvm_intel` (ou `kvm_amd`), ou reinicie o sistema.

Hosts que executam máquinas virtuais, mas não precisam de virtualização aninhada. Essa é a medida de mitigação mais eficaz, exceto pela aplicação do patch. Desativar a virtualização aninhada elimina o caminho do convidado para o host, pois a MMU-sombra só entra em ação para convidados aninhados:

# Intel
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf
# AMD
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf

A alteração entra em vigor após o módulo KVM ser recarregado (o que requer que não haja máquinas virtuais em execução) ou após uma reinicialização. Confirme com o comando `cat /sys/module/kvm_intel/parameters/nested`, que deve retornar N ou 0.

Máquinas da família RHEL que precisam manter máquinas virtuais e virtualização aninhada. Nessas distribuições, o /dev/kvm é fornecido com acesso geral (modo 0666), o que permite que um usuário local sem privilégios explore a falha diretamente. Reforce a segurança:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' \
| sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm

Verifique com o comando `ls -l /dev/kvm` e `getent group kvm`, e coloque apenas as contas que precisam do KVM no grupo `kvm`. Isso bloqueia o vetor de ataque “unprivileged-local”. No entanto, isso não impede um sistema convidado malicioso, que acessa a MMU oculta por meio de seu processo QEMU autorizado, independentemente das permissões do dispositivo do host.

Momento decisivo. Se um host não estiver executando máquinas virtuais, descarregue e bloqueie o KVM. Se estiver executando máquinas virtuais que não precisam de virtualização aninhada, desative a virtualização aninhada agora e aplique as correções em seu ritmo normal. Se estiver executando máquinas virtuais não confiáveis e precisar de virtualização aninhada — nuvem multilocatária, hospedagem, CI que cria VMs aninhadas — nenhuma alteração de configuração oferece proteção total; portanto, coloque uma correção sem reinicialização ou um kernel corrigido no início da fila. E trate uma reprodução que gere apenas um aviso como confirmação de vulnerabilidade, não como evidência de segurança.

Detecção

O Januscape não deixa nenhuma assinatura confiável no disco. A corrupção ocorre na memória do kernel do host enquanto o KVM gerencia tabelas de páginas-sombra e mapeamentos reversos; assim, as ferramentas de integridade de arquivos podem permanecer intactas mesmo após o acionamento do estado vulnerável. Isso faz com que a detecção se baseie no comportamento, e cada um dos itens a seguir é uma pista, não uma prova.

Erros ou avisos do kernel no arquivo arch/x86/kvm/mmu/mmu.c, especialmente aqueles relacionados à função pte_list_remove().
Mensagens de incompatibilidade de GFN, ou avisos da função `kvm_mmu_page_set_translation()` – a confusão entre funções e quadros torna-se visível antes da liberação.
O host entra em pânico ou sofre falhas repetidas enquanto o qemu-kvm ou o qemu-system-* estiver ativo, sem que haja nenhuma falha de hardware correspondente.
Um kernel marcado com “W” após um aviso da MMU do KVM.
Atividade de virtualização aninhada onde você não esperava, ou acesso a /dev/kvm por contas ou processos incomuns.
Uma conta ou serviço local do host que obtém privilégios logo após um surto de instabilidade do KVM-MMU, sem que haja nenhum evento correspondente de sudo ou login.

Verificar as mensagens recentes do kernel:

journalctl -k --since "24 hours ago" \
| grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

Analise a inicialização atual:

dmesg -T | grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

A ausência dessas mensagens não comprova que o host esteja atualizado. Um invasor pode evitar acionar a verificação de consistência, e um caminho vulnerável pode simplesmente ainda não ter sido acionado. Se máquinas virtuais não confiáveis estiverem em execução em um host exposto e você observar instabilidade no KVM-MMU, considere que o host merece uma análise mais detalhada — novas contas, configuração de autenticação alterada, serviços inesperados no host — em vez de interpretar os hashes válidos dos arquivos das máquinas virtuais como prova de que o host está em boas condições.

Por que o Januscape é importante

O Januscape representa uma categoria diferente de problema em relação a uma falha de escalada de privilégios do kernel local. Uma LPE local convencional exige que o invasor já tenha acesso à execução de código no host. Uma fuga do ambiente de convidado tem início a partir de código que a organização permitiu deliberadamente que fosse executado dentro de uma VM, partindo do pressuposto de que o KVM o conteria. A remoção desse pressuposto é o cerne de todo o evento.

É por isso que isso afeta mais fortemente os casos em que o isolamento do usuário é o objetivo: nuvens públicas e privadas, provedores de hospedagem, clusters multilocatários, infraestrutura de CI e compilação, ambientes de pesquisa em segurança, nuvens para desenvolvedores e qualquer plataforma que execute VMs controladas pelo cliente. O fato de essa suposição subjacente já ser antiga amplia ainda mais o impacto. Esse comportamento remonta a 2010 e se manteve ao longo de muitas gerações de kernels corporativos; portanto, dizer que “usamos uma distribuição moderna” não serve como justificativa.

A razão pela qual é fácil cometer um erro de avaliação é a mesma pela qual isso é perigoso. Três sinais plausíveis apontam para “segurança”, mas todos induzem ao erro. O EPT ou NPT de hardware dá a impressão de ter aposentado a MMU-sombra, mas a virtualização aninhada arrasta os sistemas convidados de volta para ela. A correção GFN (CVE-2026-46113) parece ter fechado esse canto da MMU, mas, na verdade, corrigiu apenas metade da falha e deixou a outra parte exposta. E um PoC que só causa falha em uma máquina de sua propriedade parece um auto-DoS inofensivo, quando, na verdade, a falha é apenas a demonstração pública, e não o limite máximo. Confie em qualquer um deles e você classificará um host vulnerável como seguro.

A relação com o CVE-2026-46113 é a principal fonte de falsa confiança. Uma equipe que corrigiu a vulnerabilidade anterior de uso após liberação (use-after-free) inesperada no GFN pode concluir que o problema de shadow-paging foi resolvido. Mas não é o caso. A correção anterior verificava se o KVM havia encontrado o quadro correto. O Januscape mostrou que o KVM também precisava verificar se havia encontrado o tipo correto de página-sombra. Uma correspondência não era suficiente, e o fechamento de um CVE não significa que ambos tenham sido resolvidos.

Lista de verificação de medidas corretivas priorizadas

Registre isso como CVE-2026-53359 (Januscape), e não como CVE-2026-46113.
Confirme se os hosts afetados possuem tanto a correção do Januscape quanto a correção relacionada ao CVE-2026-46113. Ambas são necessárias.
Fazer o inventário dos hosts com módulos KVM carregados, com o /dev/kvm presente ou com cargas de trabalho ativas do QEMU, e identificar aqueles que apresentam virtualização aninhada.
Priorize os hosts multilocatários e qualquer host que execute máquinas convidadas não confiáveis com a virtualização aninhada ativada.
Desative totalmente o KVM nos hosts que não utilizam virtualização.
Desative a virtualização aninhada quando não for necessária – isso elimina a rota de fuga do convidado não confiável.
Restrinja o acesso a /dev/kvm apenas a contas confiáveis e ao grupo kvm em hosts da família RHEL. Isso impede apenas o vetor de ataque local sem privilégios, não um sistema convidado malicioso.
Verifique explicitamente os servidores AMD – eles são afetados mesmo nos casos em que um teste realizado apenas com Intel não apresentou problemas.
Não se deve inferir a segurança com base apenas na versão do kernel, e uma reprodução que resulte apenas em um aviso deve ser considerada como exposição.
Procure por avisos do KVM GFN, falhas na função pte_list_remove() e panics inexplicáveis no host, e considere que hashes válidos dos arquivos do guest não constituem evidência suficiente sobre o host.
Aplique um kernel fixo do fornecedor e reinicie o sistema, ou utilize o patch KernelCare sem reinicialização para o kernel específico que está em execução, priorizando os hosts mais difíceis de reiniciar.
Verifique a cobertura explícita das vulnerabilidades CVE para ambas as correções, em vez de se basear nas datas de compilação.

Aplicação de patches sem reinicialização

O Januscape é o tipo de falha no hipervisor que permanece exposta muito tempo depois que um pacote corrigido já está disponível. Instalar o pacote é apenas o primeiro passo. O host ainda precisa inicializar com o kernel substituto e, em um cluster KVM, isso significa esvaziar os nós, migrar os sistemas convidados, coordenar os locatários, manter margens de capacidade e alternar as máquinas durante a manutenção. Essas restrições podem prolongar uma fuga conhecida de um sistema convidado por semanas ou meses de exposição residual, e elas são mais pesadas justamente nos hosts multilocatários que correm maior risco.

Essa alteração é uma boa candidata a um patch que não requer reinicialização: uma pequena correção na falha da MMU e no caminho de mapeamento reverso, sem nenhum estado persistente a ser transferido. O KernelCare porta ambas as correções necessárias — a correção da função Januscape (81ccda30b4e8) e a correção GFN associada (0cb2af2ea66a) — para o kernel em execução, com variantes por família de kernel para as linhas de backport do EL 5.14 e os kernels 6.x baseados na linha principal. O LibCare não se aplica, pois se trata de um bug exclusivo do kernel, sem nenhum componente de biblioteca do espaço do usuário.

Situação da versão em 29 de julho de 2026.

O KernelCare disponibiliza a correção da função Januscape e a correção complementar necessária para o CVE-2026-46113 em conjunto; portanto, a disponibilidade é indicada por família de kernel, e não por CVE.

Estável, totalmente promovido

RHEL 10 – conjunto de patches K20260703_15

Oracle Linux 10 – K20260703_16

Rocky Linux 10 – K20260703_17

AlmaLinux 10 – K20260703_18

Debian 13 – K20260706_09

Ubuntu 22.04 – K20260706_01 (_02 para arm64, _03 para o Azure, _04 para a AWS)

Ubuntu 20.04 com o kernel Jammy HWE – K20260706_06 (Azure: _05, AWS: _07)

Ubuntu 24.04 – K20260707_01 (AWS: _02)

Proxmox VE 7 (5.15) – K20260706_08

Proxmox VE 8 (6.8) – K20260707_03

Enterprise Linux 9, lançado em julho de 2026

RHEL 9 – K20260710_58

AlmaLinux 9 e CloudLinux 9 – K20260710_60

Oracle Linux 9 – K20260710_63

Rocky Linux 9 – K20260710_65

Implementação em etapas

Debian 12 – K20260709_25

Debian 11 – K20260710_11

Kernel padrão do Ubuntu 20.04 – K20260710_10

CloudLinux 8 – K20260709_27

Em fase de testes

RHEL 8 – K20260710_31

AlmaLinux 8 – K20260710_41

Rocky Linux 8 – K20260710_43

CentOS 8 – K20260710_33

Oracle Linux 8 – K20260710_35

CloudLinux 7 híbrido – K20260710_39

Ainda está aberto

Oracle UEK6, Oracle UEK7, Amazon Linux 2, Ubuntu 18.04.

O Enterprise Linux 7 é afetado, mas não há previsão de lançamento de uma correção. O impacto prático, nesse caso, é apenas a negação de serviço: um ataque DoS de locatário para host é impraticável, pois o VMX aninhado é lento o suficiente para tornar a condição de corrida não confiável, e o caminho para escalonamento de privilégios local é bloqueado pelo CONFIG_BUG_ON_DATA_CORRUPTION. Os hosts no EL7 ainda devem utilizar as medidas de mitigação de configuração mencionadas acima.

A cobertura do Enterprise Linux 9 já está disponível para o RHEL 9, AlmaLinux 9, CloudLinux 9, Oracle Linux 9 e Rocky Linux 9. Isso é importante porque o EL9 foi a plataforma que sofreu um panic fatal no nosso laboratório; portanto, os hosts expostos com EL9 continuam sendo os primeiros a receberem o patch — mas eles não precisam mais ficar dependentes de medidas de mitigação de configuração enquanto aguardam a disponibilidade de um patch. As plataformas restantes ainda sem cobertura são o Oracle UEK6 e UEK7, o Amazon Linux 2 e o Ubuntu 18.04; esses hosts ainda dependem das medidas de mitigação mencionadas acima ou de um kernel corrigido pelo fornecedor.

Inscreva-se pelo feed de testes:

sudo kcarectl --update --prefix test

Aplique a partir do feed de produção assim que for promovido:

sudo kcarectl --update

Confirme a compilação do patch em execução:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07 or later

Como o Januscape precisa das duas correções, verifique se ambas estão presentes, em vez de confiar apenas na data:

kcarectl --patch-info | grep -E

'CVE-2026-53359|CVE-2026-46113'

Dois resultados positivos constituem uma resposta clara. Um único resultado positivo para o CVE-2026-46113, por si só, não é prova de que a correção de função esteja ausente, devido ao histórico de rotulagem mencionado anteriormente — nesse caso, verifique a K-tag instalada em relação à lista de versões acima ou ao registro de cobertura do KernelCare para essa família de kernels. A data de compilação, por si só, não prova nada. Um kernel compilado após meados de junho não traz automaticamente essa correção e não garante que ambas as correções estejam presentes. Verifique o mapeamento do CVE, a K-tag, a errata do fornecedor ou diretamente o código-fonte.

O Januscape transforma uma sutil incompatibilidade de página-sombra do KVM em uma falha na fronteira entre o sistema convidado e o host. Para parques de virtualização que não podem suportar reinicializações de emergência, um patch que não requer reinicialização fecha essa fronteira no kernel em execução sem esvaziar todos os nós nem interromper seus sistemas convidados.

Adquira o KernelCare hoje mesmo →