Fragnesia (CVE-2026-46300): Uma nova vulnerabilidade de execução de código local (LPE) no kernel do Linux, pertencente à família Dirty Frag

A versão resumida

O que: Uma falha no tratamento do XFRM ESP-in-TCP pelo kernel do Linux permite que um usuário local sem privilégios induza modificações controladas em páginas armazenadas em cache pertencentes a arquivos somente leitura, incluindo binários setuid.

Impacto: Escalação de privilégios locais para o usuário root por meio da modificação do cache de páginas. O arquivo no disco permanece inalterado, enquanto a cópia armazenada em cache na memória é alterada.

Sistemas afetados: Sistemas que executam os caminhos de código skbuff afetados, incluindo kernels que já receberam a correção do Dirty Frag. O PoC público requer CONFIG_INET_ESPINTCP para acionar o bug; portanto, kernels compilados sem essa opção bloqueiam essa exploração; no entanto, a falha subjacente no skbuff pode ser acionada por meio de outros caminhos. Distribuições que restringem os namespaces de usuários sem privilégios por padrão (como a configuração do AppArmor do Ubuntu) bloqueiam parcialmente o PoC público.

Status da vulnerabilidade: PoC público divulgado no GitHub imediatamente após a divulgação.

CVE ID: CVE-2026-46300

Medidas de mitigação: Desative os módulos ESP vulneráveis ou aplique as correções do fornecedor ou as atualizações de segurança assim que estiverem disponíveis.

Status da cobertura do KernelCare (atualizado em 18/05/2026, às 13h UTC): Patches que não exigem reinicialização estão disponíveis nos feeds main + ePortal para AlmaLinux ELS/FIPS, Debian 11, Debian 12, família EL8, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy) e Ubuntu 24.04 (Noble).

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

Status da divulgação: Detalhes técnicos, orientações sobre as versões afetadas e recomendações de mitigação podem sofrer alterações à medida que os fornecedores publicarem alertas e os mantenedores de kernel a jusante concluírem os backports.

Há cinco dias, o Linux lançou correções para o Dirty Frag. Hoje, os defensores estão lidando com outra vulnerabilidade na mesma área.

Fragnesia (CVE-2026-46300) é uma vulnerabilidade de escalonamento de privilégios local recém-divulgada que tem como alvo o subsistema XFRM ESP-in-TCP do kernel do Linux. Ela foi divulgada publicamente hoje por William Bowling, em colaboração com a equipe da V12 Security, juntamente com uma prova de conceito funcional que sobrescreve /usr/bin/su por meio do cache de páginas e concede acesso de root.

A divulgação foi publicada no GitHub e no X imediatamente após o patch ter sido publicado na lista de discussão do netdev, sem qualquer período de embargo. Até o momento da publicação, nenhum CVE havia sido atribuído, e a correção candidata do upstream está no netdev aguardando revisão e incorporação.

O que torna a Fragnesia digna de destaque não é apenas a vulnerabilidade em si, mas o momento em que surgiu e sua origem. O patch proposto como correção (enviado por Bowling) cita explicitamente a correção da vulnerabilidade “Dirty Frag” (f4c50a4034e6) como um dos dois commits que ela “corrige” – o que significa que a correção original do Dirty Frag expôs um bug anteriormente latente de uma forma que se tornou praticamente explorável. Segundo relatório do Wiz, Hyunwoo Kim (o relator original do Dirty Frag) também reconheceu que o Fragnesia surgiu como um efeito colateral não intencional dos patches do Dirty Frag.

O quadro geral é preocupante: os defensores estão agora corrigindo a mesma superfície de ataque duas vezes em menos de uma semana, enquanto os criadores de exploits estão lançando novas versões quase tão rapidamente quanto as correções são disponibilizadas.

Por que a fragnesia é importante

A Fragnesia não é uma classe de bug totalmente distinta do Dirty Frag. Trata-se de outra via de exploração que passa pela mesma superfície de ataque ESP/XFRM, e a correção original do Dirty Frag, proveniente do upstream, não a impede totalmente.

O problema técnico está em skb_try_coalesce(). Quando essa função anexa fragmentos paginados de um sk_buff a outro, ela atualmente descarta o SKBFL_SHARED_FRAG , mesmo quando o buffer resultante ainda contém fragmentos de propriedade externa ou respaldados pelo cache de páginas. Isso quebra a invariante na qual o tratamento de entradas do ESP se baseia – especificamente, a função skb_has_shared_frag() , que decide se um skb não linear não clonado pode pular a função skb_cow_data(). Se pular a cópia na gravação, você obtém a descriptografia no local diretamente na página compartilhada.

Em outras palavras, a correção do “Dirty Frag” (f4c50a4034e6) adicionou código que confia na precisão do marcador “shared-frag”. O marcador não é preciso. O patch candidato para o “Fragnesia” traz duas correções: — uma para o commit do Dirty Frag e outra para um commit muito mais antigo, de 2013 (cef401de7be8) – o que indica que o bug de coalescência subjacente já existe há anos. A correção do “Dirty Frag” apenas tornou esse bug explorável de maneira útil.

Na prática, a vulnerabilidade leva ao mesmo resultado que já preocupava os defensores na semana passada: a modificação do cache de página de binários privilegiados sem alterar o arquivo subjacente no disco.

Se você já implementou a mitigação do “Dirty Frag” que desativou esp4, esp6e rxrpc, você já está protegido contra o PoC público do Fragnesia. Se você aplicou apenas a correção inicial do upstream, não está protegido.

Essa distinção é importante do ponto de vista operacional, pois reforça um padrão que os defensores vêm observando cada vez mais na exploração moderna do kernel: as correções para bugs complexos relacionados ao gerenciamento de memória estão se tornando, por si só, alvos de pesquisas para contorná-las rapidamente.

Como funciona a vulnerabilidade

Em linhas gerais, a exploração funciona assim:

1. O invasor cria um novo usuário e um namespace de rede usando unshare(CLONE_NEWUSER | CLONE_NEWNET) para obter CAP_NET_ADMIN dentro do namespace isolado.
2. Uma associação de segurança ESP-em-TCP no modo de transporte é estabelecida por meio de NETLINK_XFRM , utilizando AES-128-GCM com uma chave conhecida.
3. A vulnerabilidade prepara uma tabela de consulta de fluxo de chaves com 256 entradas usando AF_ALG , mapeando cada valor de byte possível para um nonce correspondente.
4. As páginas baseadas em arquivo são colocadas em fila em um fluxo TCP por meio da função splice().
5. O soquete é alterado para modo espintcp ULP depois que as páginas já estiverem na fila.
6. Porque skb_try_coalesce() já havia removido o marcador de fragmento compartilhado, o kernel prossegue com a descriptografia AES-GCM no próprio local, diretamente nas páginas compartilhadas armazenadas em cache.
7. O byte do fluxo de chave escolhido é submetido a uma operação XOR com a página de destino, produzindo uma gravação controlada de um único byte. Repita o processo para cada byte até que a carga útil seja gravada.

O PoC público sobrescreve a cópia armazenada em cache de

/usr/bin/su com uma pequena carga útil ELF independente de posição que executa:

setresuid(0,0,0);

execve("/bin/sh");

Essa vulnerabilidade se destaca porque não depende de uma janela de corrida restrita que precise ser bem-sucedida exatamente uma vez. O invasor executa repetidamente a primitiva de gravação até que os bytes desejados sejam gravados com sucesso, tornando o processo muito mais determinístico do que muitas vulnerabilidades históricas de condição de corrida no kernel.

A página em cache modificada pode permanecer até ser removida ou até a reinicialização do sistema, o que significa que chamadas repetidas do binário visado podem continuar concedendo acesso de root, mesmo que o hash do arquivo no disco permaneça inalterado.

Quem está mais exposto?

Os ambientes de maior risco são os sistemas que combinam:

• execução de código local não confiável,
• espelhos de namespace sem privilégios habilitados,
• cargas de trabalho multilocatárias,
• e suporte ativo ao kernel XFRM/ESP.

Isso faz com que os seguintes ambientes sejam particularmente importantes e devam ser priorizados:

• Nós de trabalho do Kubernetes
• Executores de CI/CD compartilhados
• Plataformas de hospedagem compartilhada
• Servidores do Bastion e do Jump
• Estações de trabalho para desenvolvedores
• Infraestrutura de contêineres multilocatária

Nesses sistemas, uma vulnerabilidade de escalonamento de privilégios “local” raramente se limita apenas ao âmbito local. Um contêiner comprometido, uma tarefa de CI maliciosa, uma chave SSH roubada ou um RCE em um aplicativo podem se tornar pontos de partida para o comprometimento total do host.

Aplicação de patches no Fragnesia sem reinicialização com o KernelCare

Para os sistemas mencionados acima — nós do Kubernetes multilocatários, executores de CI compartilhados, hosts bastião —, a questão prática é com que rapidez você consegue, de fato, implantar uma correção. A ferramenta de aplicação de patches sem reinicialização da TuxCare, KernelCare, disponibilizou patches sem reinicialização para a família de kernels EL8 em até 24 horas após a divulgação da vulnerabilidade “Dirty Frag” na semana passada, antes mesmo das erratas correspondentes dos fornecedores. EL9, Ubuntu, Debian e Proxmox VE seguiram na mesma onda de lançamento. Esse é o parâmetro de referência para o que significa “rápido” nessa classe de gravidade.

Para o Fragnesia, o ciclo será um pouco mais complicado. A correção no upstream ainda está no netdev aguardando revisão, o que significa que o primeiro patch do KernelCare será compilado com base em uma versão candidata. Se a versão mesclada pelo mantenedor acabar sendo diferente, espere uma recompilação. E como esse patch candidato traz uma tag `Fixes:` apontando para um commit de 2013, é provável que haja mais auditorias no `skb_try_coalesce()` – o primeiro patch lançado que não requer reinicialização pode não ser o último para essa superfície de ataque.

Essa cadência é exatamente o que ocorre na aplicação de patches sem reinicialização. Dois patches em cinco dias para o mesmo subsistema, ambos com PoCs públicos antes que as erratas do fornecedor pudessem ser atualizadas, e um terceiro provavelmente a caminho. A alternativa — que a próxima seção detalha — é a inclusão de módulos na lista negra, restrições de namespace e uma reinicialização contínua não programada assim que sua distribuição lançar um pacote do kernel. Nós do Kubernetes ficaram inoperantes duas vezes em uma semana. Executores de CI foram reiniciados no meio da compilação. Failovers de bastião que ninguém programou.

Uma observação importante: alguns scanners de vulnerabilidades continuarão sinalizando a versão do pacote do kernel sem patch após a aplicação do patch em tempo real, pois a lógica de detecção do scanner fica desatualizada em relação ao estado real do kernel em execução. O kernel está protegido. Seu painel de controle pode não refletir isso por um ou dois dias. Planeje a explicação no ticket de acordo com isso.

Se você ainda não utiliza o KernelCare e, nesta semana, sua rotina de atualizações foi interrompida, este é um bom momento para dar uma olhada. Os preços para novos clientes estão com desconto até o final de junho. Adquira o KernelCare → 

Mitigação

Mitigação imediata

A mesma lista negra de módulos usada para o Dirty Frag também bloqueia a vulnerabilidade pública do Fragnesia:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Se /etc/modprobe.d/dirtyfrag.conf já estiver presente devido a medidas de mitigação anteriores, você pode deixá-lo onde está.

Aviso operacional

Desativando esp4 e esp6 interrompe o funcionamento do IPsec e das VPNs baseadas em ESP, incluindo implantações que utilizam o strongSwan ou o Libreswan. As implantações do WireGuard não são afetadas.

rxrpc está associado a clientes AFS e, em geral, é seguro desativá-lo em servidores comuns.

Verifique as dependências operacionais antes de implementar essas medidas de mitigação em larga escala.

Restringir os espaços de nomes de usuários sem privilégios

Os sistemas Ubuntu resistem parcialmente à demonstração de conceito (PoC) pública porque o AppArmor restringe, por padrão, os espaços de nome dos usuários sem privilégios. A própria PoC orienta os usuários a desativar:

kernel.apparmor_restrict_unprivileged_userns=0

antes da exploração.

Os sistemas da família RHEL podem oferecer um nível de proteção semelhante por meio de:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

Essa é apenas uma solução parcial. Além disso, isso prejudica o funcionamento de contêineres sem privilégios de root, do Flatpak, de navegadores em sandbox e de outras ferramentas que dependem de namespaces.

Limpar o cache de páginas contaminadas

Como a vulnerabilidade altera apenas as páginas armazenadas em cache, os sistemas suspeitos de terem sido comprometidos devem esvaziar o conteúdo do cache de páginas após a mitigação:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Isso elimina a persistência imediata do cache de página, mas não garante que o invasor não tenha conseguido estabelecer uma persistência mais duradoura posteriormente. Qualquer exploração bem-sucedida deve ser tratada como um comprometimento total do host.

Aplicar correções do fornecedor

Aplique as atualizações do kernel fornecidas pelo fornecedor ou os patches dinâmicos validados assim que estiverem disponíveis para a sua distribuição.

No momento da publicação, o patch de acompanhamento proposto por William Bowling:

[PATCH net] net: skbuff: preservar o marcador de fragmento compartilhado durante a coalescência

está na lista de discussão do netdev aguardando revisão. O patch é pequeno – duas linhas em skb_try_coalesce() que preservam o SKBFL_SHARED_FRAG ao transferir descritores de fragmentos. Os mantenedores provavelmente irão incorporar uma versão disso rapidamente, mas as adaptações em distribuições posteriores levam mais tempo.

Isso é importante porque os defensores podem precisar encarar isso como um ciclo de atualizações em evolução, em vez de uma única ação de correção. As duas correções: na correção sugerem que é necessário um trabalho de auditoria mais abrangente no caminho de coalescência do skb.

Orientações para a detecção

As ferramentas tradicionais de integridade de arquivos não são adequadas para esse tipo de ataque:

• Os hashes armazenados no disco permanecem corretos
• O AIDE e o Tripwire podem indicar que não houve nenhuma modificação
• A alteração maliciosa desaparece após a limpeza do cache ou a reinicialização

A detecção comportamental é muito mais promissora.

Entre os sinais potenciais estão:

• unshare(CLONE_NEWUSER | CLONE_NEWNET) de processos inesperados
• NETLINK_XFRM atividade proveniente de cargas de trabalho não relacionadas à funcionalidade de VPN
• Excepcionalmente pesado AF_ALG uso da interface de criptografia, especialmente em loops curtos
• splice() operações de arquivos comuns em soquetes TCP, seguidas por alterações no ULP no mesmo soquete

Nenhuma dessas ações, por si só, é inerentemente maliciosa, mas a combinação delas é suspeita o suficiente para justificar regras de detecção em tempo de execução utilizando ferramentas eBPF, Falco, Tetragon ou plataformas EDR para Linux.

O panorama geral

Pesquisas recentes sobre escalada de privilégios no Linux têm apontado repetidamente para a corrupção do cache de páginas, a propriedade da memória compartilhada e falhas no processamento in-place, incluindo:

• Dirty Pipe (2022)
• Falha na cópia (2026)
• Dirty Frag (2026)
• Fragnesia (2026)

Três delas vieram à tona em apenas algumas semanas.

O tema comum está ficando cada vez mais claro: caminhos do kernel altamente otimizados, envolvendo propriedade de memória compartilhada, gerenciamento de páginas e processamento no próprio local, continuam gerando primitivas de gravação perigosas quando as suposições para casos extremos falham.

splice(), a coalescência de skb, o processamento de ESP e as interações com o cache de páginas são todos subsistemas voltados para o desempenho. Os invasores vêm comprovando cada vez mais que essas otimizações podem se tornar caminhos confiáveis para a escalada de privilégios quando a semântica de propriedade falha.

A Fragnesia também se destaca pela rapidez com que surgiu após a implementação das correções originais para o Dirty Frag. A V12 Security atribui parte do processo de descoberta às ferramentas de segurança assistidas por IA agênica e, independentemente do peso que se dê a essa afirmação, o ritmo de iteração das explorações está se acelerando. O fato de a correção proposta conter um Correções: que aponta para um commit de 2013 também sugere que essa classe de bugs ainda não foi esgotada — provavelmente há mais violações de invariantes no mesmo caminho de código aguardando para serem descobertas.

Os defensores devem partir do princípio de que essa classe de insetos ainda não concluiu sua evolução.

Resumo

Nome do artigo

Fragnesia (CVE-2026-46300): Nova vulnerabilidade de execução de código local (LPE) no Linux que contorna o patch “Dirty Frag”

Descrição

Fragnesia (CVE-2026-46300) é uma nova vulnerabilidade de execução de código local (LPE) no kernel do Linux que amplia a família Dirty Frag (CVE-2026-43284, CVE-2026-43500).

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora