CVE-2026-31431 - Script de Verificacao e Mitigacao

Este repositorio documenta um script Bash para verificar a exposicao a CVE-2026-31431 em hosts Linux, com foco em Ubuntu, e aplicar uma mitigacao simples baseada no bloqueio do modulo algif_aead.

O script opera em tres modos:

• --check: coleta informacoes do host e classifica o status.
• --mitigate: cria uma regra de modprobe para bloquear o modulo vulneravel e tenta descarrega-lo.
• --update: executa atualizacao de pacotes de kernel via apt.

Sobre a vulnerabilidade

CVE-2026-31431, tambem chamada publicamente de Copy Fail, e uma vulnerabilidade de escalacao local de privilegio no kernel Linux associada ao modulo algif_aead, que implementa a interface AEAD da API criptografica em userspace via AF_ALG.

Em termos praticos, o problema permite que um usuario local com baixa privilegio explore uma falha logica no caminho de tratamento de memoria desse subsistema e evolua para comprometimento de integridade do sistema. A classificacao publicada pelo kernel.org e refletida no NVD e CVSS 7.8, com vetor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, ou seja: o ataque exige execucao local, mas tem alto impacto em confidencialidade, integridade e disponibilidade.

Quando ela foi encontrada e divulgada

• A causa raiz exploravel foi introduzida no kernel em 2017, quando uma otimizacao "in-place" foi adicionada ao algif_aead.
• O CVE foi publicado no NVD em 22 de abril de 2026.
• A divulgacao publica mais ampla da falha, com nome Copy Fail e prova de conceito publica, ocorreu em 29 de abril de 2026.
• O fix upstream principal foi integrado ao kernel em 1 de abril de 2026, antes da divulgacao ampla aos usuarios finais.

O que ela explora

De acordo com os avisos tecnicos publicados, a falha explora a combinacao entre:

• a interface AF_ALG do kernel
• o modulo algif_aead
• uma otimizacao de operacao "in-place" introduzida em 2017
• o encadeamento dessa interface com splice()

O resultado pratico e a possibilidade de um processo local realizar uma escrita controlada de poucos bytes em paginas do page cache de arquivos legiveis. Isso e suficiente para transformar um acesso local restrito em escalacao para root em cenarios favoraveis.

Como isso afeta a empresa

O risco real nao esta apenas em "ser Linux vulneravel", mas em permitir que qualquer codigo local de baixa confianca use esse caminho do kernel. Em ambiente corporativo, isso costuma significar maior exposicao em:

• servidores multiusuario
• jump hosts e bastions
• runners de CI/CD
• workloads de containers com execucao de codigo nao confiavel
• clusters Kubernetes
• VMs que hospedam automacoes, agentes, plugins ou jobs de terceiros

Se um invasor ja obteve algum nivel de execucao local, mesmo sem root, essa CVE pode ser o passo seguinte para tomar o host. Na pratica, isso amplia o risco de:

• takeover completo do servidor
• alteracao de binarios ou artefatos locais
• roubo de credenciais, tokens e segredos residentes
• movimento lateral para outros ativos
• sabotagem de pipelines e cadeias de build

Para que serve o modulo algif_aead

O algif_aead faz parte da interface de criptografia do kernel para espaco de usuario (AF_ALG). Ele permite que aplicacoes usem primitivas criptograficas do kernel por sockets, em especial operacoes do tipo AEAD (Authenticated Encryption with Associated Data).

Esse modulo normalmente nao e essencial para a maior parte das cargas comuns de servidor. Segundo a orientacao publicada pela CERT-EU, desativar algif_aead como mitigacao temporaria:

• nao deve afetar dm-crypt ou LUKS
• nao deve afetar kTLS
• nao deve afetar IPsec/XFRM
• nao deve afetar OpenSSL, GnuTLS, NSS ou SSH em uso padrao

Por outro lado, a desativacao pode afetar:

• aplicacoes configuradas explicitamente para usar engine afalg
• software que abre sockets AF_ALG diretamente
• integracoes customizadas que usam aead, skcipher ou hash via kernel crypto API

Em outras palavras: para a maioria dos hosts corporativos, bloquear o modulo tende a ter baixo impacto. Em appliances, stacks customizadas de criptografia ou software altamente otimizado, o impacto deve ser validado antes.

Risco operacional da desativacao do modulo

Bloquear o modulo reduz a superficie de ataque imediatamente, mas tem trade-offs:

• aplicacoes dependentes de AF_ALG podem falhar ao inicializar ou perder aceleracao criptografica via kernel
• workloads customizadas podem apresentar erro apenas em tempo de execucao, nao no boot
• se o modulo ja estiver carregado, a mitigacao so fica completa apos descarrega-lo com sucesso ou reiniciar o host

Por isso, em ambiente produtivo, o ideal e aplicar a mitigacao com janela controlada e validacao minima das aplicacoes criticas.

Solucao definitiva recomendada

A mitigacao por blacklist e apenas temporaria. A correcao definitiva e:

1. instalar um kernel corrigido fornecido pelo vendor da distribuicao
2. reiniciar o host para carregar o kernel novo
3. validar que o host deixou de ser reportado como afetado
4. somente depois decidir se a regra de bloqueio do modulo ainda e necessaria

Medidas adicionais recomendadas:

• priorizar patch em hosts com usuarios locais, containers ou execucao de codigo nao confiavel
• restringir criacao de sockets AF_ALG via seccomp em containers e pipelines, quando aplicavel
• revisar onde existe uso explicito de afalg ou da crypto API do kernel
• manter inventario de kernels e status de reboot pendente
• tratar runners de CI/CD e nos Kubernetes como prioridade alta

O que o script verifica

O script inspeciona:

• hostname do host
• versao do kernel em execucao
• sistema operacional via /etc/os-release
• presenca do modulo algif_aead
• se o modulo esta carregado
• se o modulo foi bloqueado por regra de modprobe
• se o host exige reboot (/var/run/reboot-required)
• status informado pelo Ubuntu Pro com pro fix CVE-2026-31431 --dry-run, quando disponivel

Com base nisso, ele retorna uma classificacao como:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Logica de classificacao

De forma resumida:

• Se o Ubuntu indicar que o host nao esta afetado ou ja foi corrigido, o status sera PATCHED_OR_NOT_AFFECTED.
• Se o modulo algif_aead nao existir no kernel atual, o status tende a ser LIKELY_NOT_VULNERABLE.
• Se o modulo existir, mas estiver bloqueado e nao carregado, o status sera MITIGATED.
• Se o Ubuntu indicar vulnerabilidade e o modulo estiver carregado, o status sera VULNERABLE_MODULE_LOADED.
• Se o modulo existir e estiver carregavel, mas sem confirmacao de correcao, o status sera POTENTIALLY_VULNERABLE.

Requisitos

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get para o modo --update
• sudo quando executado sem root
• pro opcionalmente, para enriquecer a analise em Ubuntu

Uso

Se o arquivo do script estiver, por exemplo, como check_cve_2026_31431.sh:

chmod +x check_cve_2026_31431.sh
./check_cve_2026_31431.sh --check

Verificacao padrao

./check_cve_2026_31431.sh --check

Exemplo de saida:

Host: srv-app-01
OS: Ubuntu 24.04 LTS
Kernel: 6.8.0-58-generic
CVE: CVE-2026-31431
Module exists: 1
Module loaded: 0
Module blocked: 1
Ubuntu affected: yes
Fix available: yes
Reboot required: 0

Status: MITIGATED
Reason: algif_aead exists but is blocked and not loaded

Saida em JSON

./check_cve_2026_31431.sh --check --json

Exemplo:

{"host":"srv-app-01","os":"Ubuntu 24.04 LTS","kernel":"6.8.0-58-generic","cve":"CVE-2026-31431","module":"algif_aead","module_exists":1,"module_loaded":0,"module_blocked":1,"ubuntu_affected":"yes","fix_available":"yes","reboot_required":0,"status":"MITIGATED","reason":"algif_aead exists but is blocked and not loaded"}