PENTESTY · ANÁLISE EDITORIAL · · 4 min de leitura
Kernel Linux: o patch aprovado já está em execução?
Atualizações disponíveis e pacotes em homologação exigem decisões diferentes. O aceite precisa identificar o kernel carregado após a manutenção de cada servidor.
Por Pentesty
Separe a divulgação da entrega das correções
A notícia de 3 de novembro acompanha uma etapa de distribuição: a CVE tem data pública de 15 de outubro. O boletim da Red Hat descreve uma condição de uso de memória liberada no processamento TCP sobre IPv4, com possibilidade de execução remota de código sem autenticação. A prioridade é relacionar essa condição aos sistemas mantidos pela empresa.
A Anthropic relatou uma demonstração de pesquisa com um modelo interno e um serviço MPTCP. Esse experimento demonstra um resultado nas condições descritas pela empresa; sozinho, não confirma uma campanha contra organizações. Separe o registro de atualização da investigação de possíveis incidentes, com fontes e períodos próprios.
Associe o aviso ao produto e ao canal contratado
Em 1º de novembro, a Red Hat publicou RHSA-2026:93414 para RHEL 8, classificado como Critical, e RHSA-2026:93412 para RHEL 9 e RHSA-2026:93413 para RHEL 10, classificados como Important. Essa classificação dos avisos difere da avaliação geral Critical, CVSS 9,8, no registro da CVE. Preserve ambos os contextos na comunicação interna.
Identifique versão da distribuição, arquitetura, variante do kernel e canal de manutenção. Os três avisos incluem, respectivamente, 4.18.0-553.182.1.el8_10, 5.14.0-687.64.1.el9_8 e 6.12.0-211.72.1.el10_2. São referências dos produtos listados, sem equivalência automática para todos os kernels em nuvem, tempo real ou CoreOS. Vincule cada servidor ao aviso aplicável.
Homologue a escolha do canal antes da instalação
No comunicado de 2 de novembro, a Canonical informou correções em -proposed para Ubuntu 22.04, 24.04 e 26.04 LTS, ainda em qualificação e sem seleção automática para atualização. Na consulta de 3 de novembro, o rastreador Ubuntu ainda indicava trabalho em andamento para o pacote linux dessas versões. Consulte novamente o pacote e a variante antes da mudança.
A equipe pode avaliar um grupo controlado com o pacote em qualificação, ou aguardar o canal regular com uma exceção de risco documentada. Registre responsável, dependências, testes de aceite, janela de manutenção e condição de retorno. Habilitar -proposed indiscriminadamente aumenta o escopo da mudança e não substitui a homologação do serviço.
O aceite termina com o kernel carregado
Os avisos consultados da Red Hat e a orientação da Canonical exigem reinício para essas atualizações entrarem em efeito. Guarde o identificador do host, o pacote instalado e a versão do kernel em execução depois do reinício planejado. Compare esses dados ao aviso e registre a hora da observação; o relatório do instalador, isoladamente, não comprova qual kernel foi carregado.
Verifique inicialização, rede, armazenamento e funções críticas do serviço em um grupo representativo antes de ampliar a implantação. Inclua hosts de virtualização, cuja responsabilidade discutimos na análise sobre KVM em ARM64, e acompanhe cada membro de cluster, como no aceite de atualizações do LXD. A unidade de aceite precisa corresponder ao componente que executa o código.
Mantenha exceções e mitigações rastreáveis
A Red Hat descreve filtragem de opções IPv4 como redução de exposição, com cobertura incompleta e possíveis efeitos em aplicações. O alcance precisa considerar caminhos de rede e contêineres. Desabilitar MPTCP também não basta: os fornecedores esclarecem que ele não é condição necessária para a vulnerabilidade. Não trate uma alteração de firewall como comprovação de kernel corrigido.
Se algum servidor ficar pendente, registre motivo, contenção adotada e próxima revisão. Retire medidas temporárias apenas depois de verificar a correção e seus efeitos no tráfego esperado. A distinção entre pacote instalado e componente ativo também aparece no PHP2Shell; mantenha evidências da manutenção separadas de conclusões sobre o período anterior.
Perguntas frequentes
Instalar o pacote encerra a correção?
O aceite exige comprovar o kernel carregado após o reinício previsto pelos avisos. Relacione host, pacote, versão em execução e teste do serviço; uma instalação concluída não demonstra, sozinha, que o código novo está ativo.
Devo habilitar -proposed em toda a frota Ubuntu?
A Canonical descreve uma opção para quem realiza testes próprios de aceite. Avalie o pacote específico em um grupo controlado, com dependências e retorno definidos. Reconfirme o estado atual do canal antes de decidir a expansão.
Por que os avisos RHEL têm gravidades diferentes?
Os avisos consultados classificam RHEL 8 como Critical e RHEL 9 e 10 como Important, enquanto a CVE tem avaliação geral Critical e CVSS 9,8. Cite o produto e o aviso exatos, preservando essa diferença.
Filtrar tráfego ou desativar MPTCP resolve?
A filtragem descrita pela Red Hat reduz exposição sem impedir completamente a exploração e pode afetar cargas legítimas. MPTCP não é requisito da falha. Aplique a correção adequada ao produto e valide o kernel em execução.
Fontes e referências
- Red Hat: boletim técnico e limites das mitigações
- Red Hat: registro CVE e correções por produto
- Red Hat: RHSA-2026:93414 para RHEL 8
- Red Hat: RHSA-2026:93412 para RHEL 9
- Red Hat: RHSA-2026:93413 para RHEL 10
- Canonical: correções em homologação, 2 de novembro
- Ubuntu: situação atual dos pacotes da CVE-2026-98432
- Anthropic: demonstração de pesquisa em Linux
Análise original da Pentesty, publicada em 3 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.