## https://sploitus.com/exploit?id=0A05FCA3-9871-5C65-8763-4C1D1A44F7AC
# 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`:
```bash
chmod +x check_cve_2026_31431.sh
./check_cve_2026_31431.sh --check
```
### Verificacao padrao
```bash
./check_cve_2026_31431.sh --check
```
Exemplo de saida:
```text
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
```bash
./check_cve_2026_31431.sh --check --json
```
Exemplo:
```json
{"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"}
```
Essa saida e util para integracao com automacao, inventario ou pipelines de compliance.
## Mitigacao
O modo `--mitigate` cria o arquivo:
```text
/etc/modprobe.d/disable-algif_aead-CVE-2026-31431.conf
```
Com o conteudo funcional:
```conf
install algif_aead /bin/false
blacklist algif_aead
```
Depois disso, o script tenta remover o modulo da memoria com:
```bash
modprobe -r algif_aead
```
Uso:
```bash
./check_cve_2026_31431.sh --mitigate
```
Se o usuario nao for `root`, o script tentara usar `sudo`.
## Atualizacao
O modo `--update` executa:
```bash
apt-get update
apt-get install --only-upgrade -y 'linux-image-*' 'linux-modules-*' 'linux-aws*'
```
Uso:
```bash
./check_cve_2026_31431.sh --update
```
Esse modo tenta atualizar componentes de kernel em sistemas baseados em Debian/Ubuntu. Em outros cenarios, a etapa pode nao ser aplicavel.
## Ajuda
```bash
./check_cve_2026_31431.sh --help
```
Saida:
```text
Usage: ./check_cve_2026_31431.sh [--check|--mitigate|--update] [--json]
```
## Limitacoes importantes
- O script usa heuristicas. Ele nao prova exploracao, apenas estima exposicao e estado de mitigacao.
- A parte de `ubuntu_affected` e `fix_available` depende da presenca do comando `pro`.
- A etapa `--update` usa padroes de pacotes voltados a Ubuntu/Debian e pode nao cobrir todos os kernels customizados.
- Em algumas distribuicoes, o modulo pode existir com comportamento diferente do esperado pelo script.
- O bloqueio do modulo pode exigir reboot em alguns ambientes para garantir estado consistente.
## Fluxo recomendado
1. Executar `--check` para avaliar o host.
2. Se o modulo estiver disponivel e nao houver patch aplicado, executar `--mitigate`.
3. Executar `--update` ou aplicar a atualizacao oficial do fornecedor.
4. Reiniciar o host, se necessario.
5. Executar `--check --json` para validar o estado final e registrar evidencias.
## Observacao
Para melhorar a publicacao do repositorio, o ideal e salvar o script com um nome claro, por exemplo:
```text
check_cve_2026_31431.sh
```
## Creditos
Material organizado e publicado com creditos para `SEC17`.
Site oficial:
- `https://sec17.com`