Uma semana após a vulnerabilidade “Copy Fail” (CVE-2026-31431), o pesquisador Hyunwoo Kim divulgou uma segunda vulnerabilidade de escalonamento de privilégios locais no kernel do Linux na mesma área ampla — IPsec ESP e rxrpc — e a batizou de “Dirty Frag”. Já existe uma prova de conceito pública funcional. Qualquer usuário local sem privilégios pode utilizá-la para obter acesso root com um único comando.
A equipe de engenharia da KernelCare lançou patches em tempo real para toda a família de kernels EL8 em até 24 horas após a divulgação da vulnerabilidade, antes mesmo das erratas correspondentes dos fornecedores, com o EL9, o Ubuntu, o Debian e o Proxmox VE seguindo na mesma onda de lançamento. O patch se aplica ao kernel em execução e entra em vigor sem a necessidade de reinicialização.
Uma segunda exploração divulgada publicamente, denominada“Copy Fail 2: Electric Boogaloo”, refere-se a essa mesma vulnerabilidade sob esse pseudônimo. Não há um CVE específico para “Copy Fail 2”. Tudo o que está descrito neste comunicado se aplica.
Contexto: PoC público e relatório · Divulgação no oss-security · Entrada no NVD para CVE-2026-43284 · Correção no projeto original
Por que isso é urgente
A falha está na rota de descriptografia in-place dos módulos esp4, esp6 e rxrpc. Quando o caminho de recepção descriptografa em buffers paginados que não pertencem exclusivamente ao kernel (por exemplo, páginas de pipe que chegam ao soquete por meio de splice(2) / sendfile(2)), processos sem privilégios podem reter referências ao texto simples resultante, gerando uma operação de gravação no cache de páginas que o PoC público transforma em privilégios de root com um único comando.
O embargo de divulgação responsável foi quebrado em 7 de maio de 2026, antes que as distribuições pudessem se coordenar. Um exploit funcional foi divulgado publicamente antes que os IDs CVE fossem atribuídos e antes que as retificações dos fornecedores estivessem prontas. Em qualquer sistema em que usuários não confiáveis possam executar código, isso deve ser tratado como um evento que exige a aplicação de patch no mesmo dia.
Atualização sobre as atribuições de CVE:
- A vulnerabilidade de gravação no cache de páginas do xfrm-ESP é registrada como CVE-2026-43284.
- A vulnerabilidade de gravação no cache de páginas do rxrpc foi atribuída ao CVE-2026-43500 (registro no NVD pendente).
Patches dinâmicos do KernelCare: já disponíveis, sem necessidade de reinicialização
A KernelCare disponibilizou patches em tempo real antes das erratas dos fornecedores nas distribuições compatíveis:
- Família EL8 (RHEL 8, CentOS 8, Oracle Linux 8, CloudLinux 8, CloudLinux 7 Hybrid, AlmaLinux 8, Rocky Linux 8)
- Família EL9 (RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9)
- Ubuntu 22.04 LTS (Jammy), incluindo as variantes AWS e HWE
- Debian 12 (Bookworm)
- Proxmox VE 7 (kernel 5.15) e Proxmox VE 8
Os clientes recebem a correção automaticamente na próxima execução do comando `kcarectl –update`.
Os ELS para kernels FIPS também são abordados
Os kernels com suporte de ciclo de vida infinito (ELS) da TuxCare, validados pela FIPS, para o AlmaLinux 9.2 e 9.6 receberam as correções. Os clientes do ELS-FIPS recebem a correção por meio do mesmo canal de distribuição do KernelCare (versões K20260508_20 e K20260508_19, respectivamente), sem a necessidade de nenhuma ação adicional.
O que os clientes da KernelCare precisam fazer
Na maioria dos casos, nada. Se a atualização automática do kcarectl estiver ativada (configuração padrão), o patch será baixado e aplicado na próxima verificação programada. Para aplicá-lo imediatamente:
kcarectl --update
Como verificar se você está com as atualizações instaladas
Verifique a data de compilação do patch carregado:
kcarectl --info | grep kpatch-build-time
Qualquer patch com data de 8 de maio de 2026 ou posterior contém a correção. Para confirmar por meio da referência CVE:
kcarectl --patch-info | grep -i 'CVE-2026-43284\|CVE-2026-43500\|dirty.frag\|xfrm'
A string da versão do kernel retornada pelo comando `uname -r` não muda com o KernelCare, já que o kernel em execução é corrigido na memória, em vez de ser substituído no disco.
Medida temporária de mitigação (caso não seja possível atualizar imediatamente)
Se não for possível aplicar o patch ao vivo do KernelCare neste momento, coloque os módulos esp4, esp6 e rxrpc na lista negra para que não possam ser carregados e, caso já estejam presentes, descarregue-os:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
Para reverter após a aplicação do patch em produção:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Compatibilidade: esp4 e esp6 são as transformações ESP do lado do kernel utilizadas pelo IPsec. Desativá-las interrompe os túneis IPsec que dependem do caminho de dados do kernel na máquina afetada. Não aplique essa medida de mitigação em hosts que terminam ou transitam túneis IPsec, strongSwan ou Libreswan. rxrpc é o transporte AF_RXRPC utilizado quase exclusivamente por clientes AFS e não está presente em servidores típicos de hospedagem na web.
Restaurar os binários do cache de páginas após a mitigação
A vulnerabilidade pode modificar arquivos binários legítimos do sistema no cache de páginas como parte do processo de obtenção de privilégios de root; portanto, a medida de mitigação por si só não é suficiente em sistemas que possam ter sido alvo de ataques antes de sua implementação. Após a mitigação, esvazie o cache de páginas:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Links
- PoC da Canonical (Hyunwoo Kim / V4bel)
- Relatório do pesquisador (dirtyfrag.io)
- Tópico sobre divulgação de vulnerabilidades do oss-security
- tópico no lore.kernel.org
- Entrada no NVD para CVE-2026-43284
- Correção no upstream (netdev/net.git, commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4)
Ainda não está usando o KernelCare?
O KernelCare fornece patches em tempo real para vulnerabilidades (CVEs) do kernel em sistemas em execução, sem a necessidade de reinicialização e sem janela de manutenção. O mesmo modelo de entrega que corrigiu a vulnerabilidade “Dirty Frag” em até 24 horas após a divulgação pública se aplica a todas as vulnerabilidades (CVEs) de alta gravidade do kernel daqui em diante.
