Script de Validação Defensiva para CVE-2026-23111

Visão Geral

CVE-2026-23111 é uma vulnerabilidade do kernel Linux em nf_tables que pode ser explorada para escalonamento de privilégios local por um usuário não privilegiado em sistemas onde namespaces de usuário e nftables estão disponíveis.[1][2] Avisos públicos de fornecedores e governos descrevem-na como um problema local que afeta distribuições Linux e enfatizam a correção como principal solução.[3][4]

Este repositório contém um script de validação defensiva projetado para ajudar a avaliar se um host expõe as condições técnicas associadas a esta CVE sem fornecer um exploit de escalonamento de privilégios. Ele verifica condições relevantes de kernel e tempo de execução, opcionalmente carrega o módulo nf_tables para testes funcionais completos, tenta um caminho de validação não privilegiado controlado usando unshare e nft, coleta rastreios de diagnóstico locais e classifica o host em vereditos operacionais como provavelmente seguro, bloqueado por política local ou caminho exposto disponível.[1][5]

O que é a CVE

De acordo com o NVD, CVE-2026-23111 é uma vulnerabilidade do kernel Linux em nf_tables resolvida como uma correção de bug lógico no netfilter e é explorável para escalonamento de privilégios local a partir de um usuário não privilegiado através de namespaces de usuário e nftables em configurações afetadas.[1] O aviso de segurança da Ubuntu descreve o mesmo caminho de exploração de alto nível e acompanha os estados de pacotes afetados e corrigidos por versão.[2]

A Red Hat afirma que um usuário local com baixos privilégios pode explorar o problema para causar negação de serviço ou potencialmente alcançar escalonamento de privilégios, e documenta um caminho de mitigação baseado em impedir que o módulo nf_tables seja carregado quando isso for operacionalmente aceitável.[3] A orientação nacional do Centro Canadense de Segurança Cibernética também aponta organizações afetadas para atualizações do fornecedor e menciona a regeneração do initramfs quando mitigações de bloqueio de módulo são usadas.[4]

O que o script faz

O script destina-se à avaliação defensiva de exposição, não à exploração. Ele foi projetado para:

• Identificar o kernel em execução, a família de distribuição e as configurações relevantes de hardening em tempo de execução.
• Verificar se CONFIG_USER_NS e CONFIG_NF_TABLES parecem estar presentes.[1]
• Inspecionar kernel.unprivileged_userns_clone e user.max_user_namespaces para estimar se namespaces de usuário não privilegiados estão disponíveis.
• Detectar se uma negação hard do modprobe (install nf_tables /bin/false) ou uma blacklist fraca está em vigor para o módulo nf_tables.
• Verificar o changelog do RPM do kernel do fornecedor quanto a uma entrada de backport da CVE-2026-23111 (somente família RHEL).
• Identificar /proc/kallsyms para o símbolo vulnerável (nft_map_catchall_activate) versus o símbolo pós-correção (nft_catchall_set_activate) antes de qualquer interação com o módulo.
• Opcionalmente carregar nf_tables via modprobe quando --allow-load-module for especificado (veja abaixo) e descarregá-lo automaticamente na saída.
• Executar um passo de validação restrito com unshare -U -n --map-root-user + nft quando o módulo estiver carregado, e registrar stdout, stderr e logs recentes do kernel.
• Verificar se unshare --user realmente cria um namespace e se CAP_NET_ADMIN é funcional dentro dele, para confirmar se as restrições do AppArmor ou SELinux são realmente eficazes.
• Destacar se controles de segurança locais como AppArmor ou SELinux parecem bloquear o caminho testado.[6]
• Emitir saída orientada a vereditos com destaque de cor opcional para facilitar a triagem.

O script armazena logs em um subdiretório do diretório do script e os remove por padrão, a menos que --keep-logs seja usado.

Política de carregamento de módulo

Por padrão, o script nunca carrega nf_tables. Se o módulo não estiver carregado quando o script iniciar, todos os testes funcionais de nft são ignorados e o veredito é derivado apenas da versão do kernel, impressão digital do kallsyms, configuração do modprobe, changelog do RPM e evidências de política LSM/sysctl.

Este padrão conservador evita expandir involuntariamente a superfície de ataque em hosts de produção. Para habilitar testes funcionais completos em um sistema controlado ou instrumentado, use --allow-load-module como root (veja abaixo).

Uso

# Padrão — sem carregamento de módulo, veredito apenas baseado em evidências de política
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Teste funcional completo — carrega (e descarrega) nf_tables, requer root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Opções

Opção	Descrição
--allow-load-module	Autoriza o script a carregar nf_tables via modprobe se o módulo ainda não estiver carregado. Habilita o exercitador completo do caminho nft catchall e o teste de eficácia de CAP_NET_ADMIN. O módulo é descarregado automaticamente na saída. Requer root. Recusado se uma negação hard do modprobe já estiver em vigor. Use apenas em sistemas não produtivos ou instrumentados.
--color	Habilita saída colorida no stdout quando o terminal suportar.
--keep-logs	Mantém logs e rastreios sob o diretório do script em vez de excluí-los na saída.
--help	Exibe informações de uso e sai.

Quando usar --allow-load-module

Use --allow-load-module quando precisar do veredito de maior confiança em uma VM de teste isolada, não produtiva ou construída para este fim. Cenários típicos:

• Um kernel na faixa vulnerável está sendo validado antes de implantar a correção do fornecedor.
• O sistema de teste tem KASAN ou outra instrumentação habilitada e você deseja observar rastreios do kernel.
• O módulo não está em uso no host alvo e uma verificação completa de ponta a ponta é necessária para evidências de auditoria.

Não use --allow-load-module em hosts de produção onde nf_tables é intencionalmente bloqueado ou onde carregá-lo violaria uma política de hardening.

Gatilhos de segurança para --allow-load-module

Antes de tentar carregar o módulo, o script aplica as seguintes verificações e sai com erro se alguma falhar:

1. Uma negação hard do modprobe (install nf_tables /bin/false) não deve estar presente em /etc/modprobe.d/.
2. modprobe deve estar disponível no sistema.
3. O script deve estar sendo executado como root (uid 0).

Se o módulo for carregado com sucesso pelo script, modprobe -r nf_tables é chamado na saída via armadilha cleanup(), independentemente de como o script termina (sucesso, erro ou CTRL+C).

Modelo de veredito

O script usa vereditos operacionais em vez de resultados de exploração: