Fragnesia CVE-2026-46300: corrupção de memória em fragmentos do kernel Linux

A Fragnesia (CVE-2026-46300) corrige uma falha em skb_try_coalesce: ao combinar buffers de rede, o kernel podia perder a marcação de que um fragmento era compartilhado. Escritas posteriores podiam modificar páginas que deveriam permanecer protegidas.

O que aconteceu

SKBs representam pacotes dentro da pilha de rede. O marcador SKBFL_SHARED_FRAG informa que a memória do fragmento tem outro proprietário e não pode ser alterada em lugar. A perda dessa informação durante a coalescência permite que consumidores posteriores, como ESP/IPsec, escrevam sobre a página original.

O efeito é corrupção de memória e pode compor elevação local de privilégio. Todas as linhas AlmaLinux 8, 9 e 10 entram pelo caminho ESP; AlmaLinux 9 e 10 podem ter uma superfície adicional via rxrpc quando o pacote de módulos parceiro está instalado.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

A presença de rxrpc não é necessária para o caminho ESP. No AlmaLinux 8, rxrpc não está fornecido como módulo, mas a distribuição ainda é afetada pelo fluxo IPsec descrito no advisory.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto. CVSS 7,8. O ataque exige acesso local, porém pode produzir impacto total após elevação. Servidores multiusuário devem priorizar o rollout mesmo sem uso intencional de IPsec.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Compare o kernel em execução e procure o módulo parceiro/rxrpc apenas para caracterizar a superfície adicional.

uname -r
rpm -q kernel --last | head
rpm -q kernel-modules-partner 2>/dev/null
lsmod | grep -E 'rxrpc|esp4|esp6'

Módulo ausente reduz uma rota, mas não elimina a falha ESP. O critério definitivo é executar um kernel igual ou posterior ao build corrigido da sua linha, ou livepatch oficialmente confirmado.

Como corrigir ou mitigar

Atualize o kernel da distribuição e reinicie. Se houver KernelCare, force a atualização e confirme especificamente a CVE antes de adiar reboot. Não remova módulos essenciais sem entender VPNs, IPsec e serviços dependentes.

dnf update 'kernel*'
reboot
uname -r

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Teste conectividade, VPN/IPsec, firewall, interfaces e aplicações. Verifique journal e dmesg em busca de corrupção ou oops. Em caso de sinal anterior, faça análise de contas, credenciais e persistência.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

A WebinHost usa inventário de kernel e KernelCare em ambientes compatíveis para reduzir a janela sem reboot. Quando um livepatch não cobre o build, a atualização completa e a reinicialização são programadas. Imunify360 e CageFS reduzem a chance e o alcance do estágio local.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

• AlmaLinux — advisory Fragnesia
• CVE.org — CVE-2026-46300

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.