Voltar às atualizações
New releaseAug 17, 2026

vcheck v1.6.3

Ferramenta de detecção e mitigação de vulnerabilidades para os bugs Copy Fail e Dirty Frag (CVE-2026-31431, CVE-2026-43284, CVE-2026-43500)

Compartilhar

vcheck

Auditar um host Linux remoto via SSH para as vulnerabilidades de módulo de kernel Copy Fail e Dirty Frag e, opcionalmente, aplicar mitigações:

CVENameMódulos afetados
CVE-2026-31431Copy Failalgif_aead
CVE-2026-43284Dirty Frag (IPsec)esp4, esp6, ipcomp4, ipcomp6, xfrm_user
CVE-2026-43500Dirty Frag (RxRPC)rxrpc, kafs

Para cada módulo afetado, o vcheck relata se ele está atualmente carregado, embutido no kernel em execução, possui rastros passados nos logs do kernel, possui sockets AF_ALG ativos (apenas Copy Fail) e se já está na lista negra em /etc/modprobe.d/.

Com -fix, o vcheck relata o estado inicial, escreve um trecho cve-XXXX-XXXXX-disable.conf para qualquer módulo que ainda não esteja na lista negra, então reexecuta as verificações e relata o estado final. Com -fix -unload, o vcheck também tenta descarregar módulos afetados que estavam carregados antes da correção, então usa a verificação final para confirmar se ainda estão carregados. Com -fix -rebuild-initramfs, o vcheck reconstrói o initramfs para o kernel atualmente em execução (apenas) após um trecho ser escrito, para que a lista negra seja incorporada na próxima imagem de inicialização. As entradas de kernel mais antigas mantêm seu initramfs original como fallback.

Use -fix apenas após uma execução somente de verificação

Sempre execute o vcheck sem -fix primeiro. Leia o relatório e confirme que os módulos afetados são seguros para desabilitar neste host antes de executar novamente com -fix. Desabilitar módulos do kernel dos quais cargas de trabalho legítimas dependem pode afetar usuários e quebrar aplicações.

Em particular:

  • Trate -fix como seguro apenas quando nenhum dos módulos afetados estiver atualmente carregado — ou seja, cada módulo é relatado como mitigated ou module not blacklisted (sem linhas VULNERABLE ou blacklisted but currently loaded). Um módulo carregado quase sempre significa que algo no host está usando-o ativamente; verifique isso antes de colocar na lista negra.
  • Os módulos IPsec (esp4, esp6, ipcomp4, ipcomp6, xfrm_user) são necessários para qualquer implantação IPsec/strongSwan/WireGuard-over-IPsec/IKE. Os módulos ipcomp4/ipcomp6 implementam compressão de carga útil IPComp e podem ser auto-negociados como parte de uma SA IPsec mesmo quando não configurados explicitamente. Não coloque nenhum deles na lista negra em um gateway VPN, endpoint IPsec ou em qualquer lugar onde ip xfrm policy retorne regras. Note que o módulo de framework xfrm_algo está intencionalmente não nesta lista — de acordo com orientações de fornecedores (Red Hat, Ubuntu, AWS), bloquear os módulos de protocolo ESP e IPComp mais a interface de configuração netlink xfrm_user é suficiente, e colocar xfrm_algo na lista negra quebraria todas as outras transformações xfrm sem benefício extra.
  • Os módulos RxRPC (rxrpc, kafs) são necessários para qualquer host que monte sistemas de arquivos AFS. Desabilitá-los quebrará essas montagens na próxima inicialização.
  • algif_aead expõe criptografia do kernel através da família de sockets AF_ALG. Raramente é usado diretamente por código de aplicação, mas verifique listando sockets ativos (ss -p --af-alg) e verificando consumidores no espaço de usuário antes de colocar na lista negra.

Os trechos de lista negra que o vcheck escreve só entram em vigor no momento do carregamento do módulo (tipicamente na próxima inicialização, ou modprobe -r <módulo> enquanto o sistema está ocioso). Um módulo que já está carregado continuará em execução mesmo após -fix — o vcheck relatará isso como blacklisted but currently loaded; run 'modprobe -r' or reboot. Passar -unload junto com -fix faz com que o vcheck execute modprobe -r para módulos afetados carregados após escrever os trechos de lista negra. Use isso apenas quando tiver confirmado que os módulos são seguros para remover do kernel em execução.

Passar -rebuild-initramfs com -fix regenera o initramfs para o kernel atualmente em execução apenas (update-initramfs -u -k $(uname -r) no Debian/Ubuntu, dracut -f --kver $(uname -r) no RHEL/Fedora). Outros kernels instalados mantêm seu initramfs existente inalterado, então se algo der errado após a reinicialização, você pode escolher uma entrada de kernel mais antiga no menu de inicialização e se recuperar. Futuras instalações de kernel reconstroem seu próprio initramfs a partir do estado atual de /etc/modprobe.d/, então a lista negra se propaga automaticamente sem precisar executar o vcheck novamente. Se nem update-initramfs nem dracut estiverem presentes (ex.: Arch, Alpine, imagens imutáveis), o vcheck avisa e continua — reconstrua manualmente com a ferramenta da distribuição antes de reinicializar.

A reconstrução pode levar vários minutos (especialmente dracut em hosts com muitos drivers), o que excederia o -command-timeout diagnóstico. Ela é executada sob seu próprio -initramfs-timeout (padrão 10m) para que a reconstrução tenha o espaço necessário enquanto as verificações rápidas mantêm seu orçamento apertado. Aumente -initramfs-timeout para hardware lento, ou passe 0 para desabilitar o timeout completamente. Durante comandos remotos de longa duração, o vcheck envia solicitações SSH keepalive a cada 30s por padrão para evitar que timers ociosos de NAT/firewall derrubem a conexão. Ajuste isso com -ssh-keepalive, ou passe 0 para desabilitar.

Instalação

Homebrew (macOS):

brew install --cask krisiasty/tap/vcheck

Binários pré-compilados para Linux, macOS e Windows são publicados na página de releases.

A partir do código fonte (requer Go 1.26+):

go install github.com/krisiasty/vcheck@latest

Uso

vcheck -host HOST [flags]

Categorias