Use uma tag de release para controle de mudanças: https://raw.githubusercontent.com/haydenjames/CVE-2026-31431-check/v1.0.3/cve-2026-31431.sh.

-q para saída de frota em uma linha. -h para ajuda. Código de saída 0 ok, 1 vulnerável, 2 desconhecido.

Uso em frota

-q imprime uma linha por host, então você pode encaminhá-lo por qualquer executor remoto que já use:

Os códigos de saída (0 ok, 1 vulnerável, 2 desconhecido) também funcionam se suas ferramentas agregarem por status.

Requisitos

bash 4+, além dos usuais awk/grep/sed/lsmod/modprobe. Se python3 estiver disponível, ele também testará a acessibilidade do socket AF_ALG; caso contrário, essa verificação é ignorada. A verificação em si não precisa de root. Aplicar a mitigação precisa.

O que ele verifica

1. Estado do algif_aead. Embutido, módulo carregável, carregado ou ausente. Lê /boot/config-* ou /proc/config.gz, com fallback para lsmod. 1b. Estado do authencesn. De acordo com o aviso upstream, este é o módulo que realmente contém o bug — algif_aead é um dos caminhos de acesso, IPsec é outro. Detectado via lsmod/modinfo e configuração.
2. Socket AF_ALG. Se o espaço do usuário consegue realmente abrir um. Detecta bloqueios de seccomp e LSM (usa Python se disponível).
3. Mitigações. Procura por arquivos de blacklist do modprobe (para qualquer um dos módulos) e verifica se a blacklist realmente prevalece via modprobe -n -v. Também sinaliza o truque quebrado do DefaultRestrictAddressFamilies do systemd [Manager] que tem circulado — essa diretiva só funciona em units, não em system.conf.d. Informa o status do SELinux e do AppArmor.
4. Pacote do kernel vs. em execução. Detecta o caso em que você instalou um kernel corrigido, mas ainda não reiniciou com ele.

Vereditos

• OK — o AF_ALG não está acessível, ou o módulo não está presente, ou sua blacklist funciona.
• REBOOT NEEDED — kernel corrigido instalado, você ainda está no antigo.
• VULNERABLE — o módulo está carregado sem um kernel corrigido instalado, ou está embutido no kernel e há um pacote corrigido disponível.
• LIKELY PATCHED — o módulo está carregado, mas o kernel em execução está atualizado. O script não consegue inspecionar um módulo carregado para distinguir uma versão corrigida de uma vulnerável, então este veredito depende do seu gerenciador de pacotes. Confirme no rastreador de CVEs da sua distribuição.
• AT RISK — o módulo pode ser carregado e nada está impedindo isso.
• WAITING ON VENDOR PATCH — o kernel está atualizado, mas algif_aead está embutido. Veredito de melhor esforço; ele depende dos códigos de saída do dnf check-update, que podem ser diferentes de zero por motivos não relacionados (rede, metadados desatualizados). Não presuma que você está esperando sem antes verificar o rastreador da sua distribuição.

Mitigação provisória

De acordo com o aviso upstream, o bug está na verdade no módulo de criptografia authencesn — algif_aead é apenas um dos caminhos de acesso. Coloque ambos na blacklist para ficar seguro:

Se o rmmod disser "module is in use", algo na máquina está usando ativamente AF_ALG ou IPsec (algumas VPNs, criptografia de disco, ferramentas de criptografia no espaço do usuário). Não force a remoção. Aplique o patch e reinicie.

Se o código vulnerável estiver compilado no seu kernel, a blacklist não vai ajudar. Só uma atualização do kernel corrige isso.

Testado em

AlmaLinux 8, AlmaLinux 9.7, CentOS 7 (TuxCare ELS), Ubuntu 22.04, Ubuntu 24.04.

Discussão

• Aviso upstream: lista de discussão oss-security — fonte primária.
• Tópico do fórum: CVE-2026-31431 — perigo (linuxcommunity.io)
• Problemas: GitHub

Créditos

Relatos de bugs que moldaram a v1.0.1:

• u/throwaway234f32423df — apontou que a atualização da blacklist do kmod no Ubuntu não estava sendo detectada, causando falsos vereditos de VULNERABLE em hosts Ubuntu corrigidos.
• u/aliendude5300 — observou que um módulo carregado que foi corrigido localmente ainda seria relatado como VULNERABLE.

Licença

MIT — veja LICENSE.