Gestão de risco no kernel
CVE-2026-98432: mitigar não é corrigir o kernel
Resposta anónima à CVE-2026-98432: verificar a distribuição, aplicar mitigação temporária na firewall, testar serviços e planear a correção definitiva do kernel.
Na CVE-2026-98432, ter uma mitigação temporária e executar um kernel corrigido são estados diferentes. A passagem de trabalho precisa de preservar essa distinção.
Começar pela distribuição e pelo kernel ativo
O boletim da Red Hat descreve uma falha use-after-free no processamento IPv4 TCP do Linux. A sua natureza de rede exige uma resposta de infraestrutura, para além da aplicação web.
O aviso da AlmaLinux documenta versões afetadas, pacotes corrigidos específicos da distribuição e filtragem temporária. Ter MPTCP desligado não comprova que a falha subjacente está corrigida.
Na avaliação anonimizada documentada a 1 de novembro de 2026, foram verificados a distribuição, o kernel ativo, os kernels instalados e os pacotes disponíveis nos repositórios oficiais de produção do servidor. O pacote corrigido ainda não estava disponível nesses repositórios no momento da consulta.
Uma comparação com versões upstream seria insuficiente porque os pacotes da distribuição podem incluir backports. Da mesma forma, um kernel instalado não comprova que a máquina arrancou com ele. O inventário precisava de distinguir os dois estados.
Aplicar uma mitigação delimitada e preparar a saída
A resposta documentada aplicou filtragem temporária de rede após verificações de compatibilidade, manteve MPTCP desligado e preparou reversão. As regras de firewall existentes foram preservadas. Não foi instalado um kernel de testing nem reiniciado o servidor.
Foram verificadas a sintaxe do filtro, o serviço dedicado e as definições de persistência. A persistência foi configurada e inspecionada, mas não testada através de reboot. Esta distinção faz parte do registo de aceitação.
Uma mitigação de rede deve ser avaliada face às cargas reais do servidor, incluindo rede de contentores e eventuais dependências de opções IPv4. Não deve ser copiada de um artigo para uma shell de produção sem rever essas dependências.
O estado após esta intervenção era mitigação temporária aplicada, correção definitiva do kernel pendente. A gestão técnica do servidor inclui manter essa tarefa aberta, mesmo quando os sites públicos continuam a responder normalmente.
Validar continuidade e acompanhar a correção pendente
As verificações registadas compararam o estado dos serviços e uma amostra de respostas HTTPS e assets públicos antes e depois da intervenção. Não foram observadas regressões nesses testes. Problemas anteriores de acesso público, DNS e certificados foram mantidos separados.
Foram testes de serviços e HTTP, sem aceitação funcional completa nem teste da mitigação através de exploração. Não foi executado um exploit. Uma homepage a funcionar não comprova que uma vulnerabilidade do kernel está encerrada.
Foi configurado acompanhamento da disponibilidade dos pacotes oficiais de produção e do estado da mitigação. Faltava preparar uma atualização de kernel autorizada, planear a retoma dos serviços e sessões, arrancar com o kernel corrigido e validar o estado resultante.
Esta nota regista a intervenção documentada a 1 de novembro de 2026. Não é uma página de estado em tempo real de servidores nem uma garantia atual de disponibilidade nos repositórios. Uma nova intervenção exige consulta atualizada dos avisos e pacotes, apoiada por revisão de segurança, plano de recuperação e responsabilidade pelo acompanhamento.
Conclusão prática
- Usar o aviso da distribuição e a evidência dos pacotes.
- Distinguir mitigação, instalação e kernel em execução.
- Registar a configuração de persistência separadamente de um teste de reboot.
- Manter a atualização definitiva aberta até à ativação e validação.