A falha de fragmentação do IPv6 que compromete o isolamento dos contêineres no EL10

A versão resumida

O que: Uma vulnerabilidade no Linux que permite a escalada de privilégios locais e a fuga do contêiner, apelidada de ipv6-frag-escape. Um erro aritmético no caminho de saída dos pacotes IPv6 (__ip6_append_data()) define o tamanho do cabeçalho linear de um buffer de soquete como menor do que fraggap bytes; portanto, uma cópia posterior causa um estouro no skb_shared_info no final da mesma alocação. Esse estouro de pilha dentro do bloco é suficiente para pegar um processo sem privilégios dentro de um contêiner e transformá-lo em root no host. Nenhum CVE havia sido atribuído até o momento da publicação.

Impacto: Uma demonstração pública de conceito divulgada pelo sgkdev (github.com/sgkdev/ipv6_frag_escape) gera um shell root interativo nos namespaces iniciais e no sistema de arquivos raiz do host, a partir de um processo sem privilégios dentro de um contêiner isolado da rede. O arquivo README lista os alvos testados, incluindo o CentOS Stream 10 na versão 6.12.0-242.el10 e o RHEL 10 na versão 6.12.0-228.el10. A KernelCare reproduziu o acesso root no host internamente no AlmaLinux 10.2 (6.12.0-211.7.3.el10_2) em 29 de junho de 2026 – uid=0 nos namespaces init, na primeira tentativa.

Status: Este é um bug da ramificação principal, corrigido no código-fonte original no Linux 7.2-rc1 por meio de um commit de mesclagem 38becddc, que inclui a correção para IPv6 736b380e28d0 e o equivalente em IPv4 eca856950f7c. A versão afetada é a 6.6 até a 7.1. Até esta manhã, não havia backports de distribuição; isso já está mudando – o AlmaLinux incorporou as atualizações do upstream para IPv4/IPv6 fraggap correções no código-fonte do pacote do kernel às 08h51 UTC do dia 30 de junho (6.12.0-211.28.2). Verifique os repositórios da sua distribuição antes de presumir que ainda está aguardando uma correção.

Gravidade: Alta para sistemas EL10 expostos. Vetor de ataque local, baixa complexidade uma vez que os pré-requisitos estejam presentes, sem interação do usuário e um exploit público funcional contra o EL10 padrão. Não há pontuação CVSS, pois ainda não há um CVE. Classe do bug: estouro linear de heap/slab → uso de página após liberação (use-after-free) → escalonamento de privilégios e fuga do namespace.

Por que isso é importante: O gatilho pode ser acessado por qualquer processo sem privilégios — o commit da correção original afirma isso diretamente: um soquete UDPv6 que utiliza MSG_MORE juntamente com MSG_SPLICE_PAGES. Não é necessária nenhuma capacidade de host, apenas acesso a espaços de nome de usuários sem privilégios dentro do contêiner. Hosts de contêineres, hospedagem compartilhada, executores de CI e sistemas Linux multilocatários são exatamente os ambientes em que essa vulnerabilidade se manifesta, pois a exploração ocorre do lado errado da barreira em torno da qual essas plataformas são construídas.

Faça isso agora: Aplique um kernel fixo ou um KernelCare patch que não exija reinicialização, quando disponível. Até lá, a solução provisória mais eficaz para o EL10 é inicializar com init_on_alloc=1, o que faz com que a exploração pública resulte em uma falha do kernel em vez de um shell de root — essa já é a configuração padrão em tempo de compilação no Ubuntu e no Debian, e é por isso que, nessas distribuições, o mesmo bug causa apenas um ataque DoS. Quando sua carga de trabalho permitir, desativar os namespaces de usuários sem privilégios elimina a via de fuga. Considere ambas as medidas como soluções provisórias.

A versão completa

O “ipv6-frag-escape” é mais um caso em que um bug do kernel do Linux passou de uma “pequena correção aritmética” para uma “vulnerabilidade pública de acesso root” antes que a maioria das organizações tivesse um CVE, uma regra de scanner ou um comunicado do fornecedor para tomar medidas.

A KernelCare tomou conhecimento da demonstração de conceito (PoC) divulgada publicamente em 29 de junho e reproduziu a vulnerabilidade de acesso a root no host internamente em uma máquina AlmaLinux 10.2 padrão na manhã seguinte, tendo um patch que não requer reinicialização em fase de compilação logo em seguida.

O repositório se descreve como uma ferramenta confiável para escapar de contêineres e jaulas sem privilégios no CentOS e no RHEL 10, aproveitando um bug de fragmentação de IPv6 — agora corrigido — em __ip6_append_data() que gera um estouro linear dentro da placa em skb_shared_info.

Uma observação importante a se ter em mente antes de entrarmos nos detalhes: trata-se de um bug do kernel principal, não de uma peculiaridade do EL10. Todos os kernels da versão 6.6 à 7.1 que não incluem a correção contêm o código vulnerável. O EL10 é simplesmente o único alvo para o qual existe, atualmente, um exploit público e já utilizado para ataques, e os pontos de entrada desse exploit – um EL10 uname verificação, paginação em 5 níveis, a opção “init-on-alloc” desativada – são características da arma, não do bug.

Como funciona a vulnerabilidade

A sequência de eventos vai desde uma operação de gravação em um soquete sem privilégios até um shell de root no host:

[Unprivileged socket input]
│  UDPv6 + MSG_MORE + MSG_SPLICE_PAGES
▼
[__ip6_append_data() miscalculation]
│  linear head under-sized by fraggap bytes
▼
[Linear slab overflow]
│  writes past skb->end into skb_shared_info
▼
[Page use-after-free]
│  put_page() drops a ref on an attacker-owned page
▼
[Dirty-Pagetable reclamation]
│  freed page reused as a leaf page table → kernel R/W
▼
[Host namespace escape]
│  credentials overwritten, SELinux neutered, core_pattern hijacked
▼
[Host root shell (uid=0)]

O erro de alocação. Em net/ipv6/ip6_output.c, quando __ip6_append_data() segue o ramo de alocação por páginas que calcula alloclen = fragheaderlen + transhdrlen e pagedlen = datalen - transhdrlen. O problema é que datalen já inclui fraggap – bytes transportados do skb anterior que, em seguida, são copiados para o cabeçalho linear. Portanto, o cabeçalho está com um déficit exatamente de fraggap bytes enquanto pagedlen é superestimado no mesmo valor.

O transbordamento. A cópia subsequente sobrescreve o conteúdo anterior skb->end para o skb_shared_info localizado na extremidade do próprio objeto `head` do pacote. Um estouro de pilha linear limpo, dentro do bloco.

O gatilho. Um processo sem privilégios acessa o caminho com falha por meio de um soquete UDPv6 usando MSG_MORE juntamente com MSG_SPLICE_PAGES. Esse erro de contagem foi introduzido já na versão 6.0 pelo caminho de envio sem cópia, mas permaneceu inacessível até que o MSG_SPLICE_PAGES No ponto 6.6, o tratamento permitiu que o caminho continuasse, em vez de retornar -EINVAL. É por isso que 6,6 é o limite inferior.

Estouro na operação de leitura/gravação do kernel. A corrupção dá o controle do único nr_frags byte em skb_shared_info. Com um ponteiro de página do buffer de canal pré-inserido em uma área não inicializada frags[] desmontagem de slot e soquete (skb_release_data() → put_page()) insere uma referência em uma página que ainda está sob o controle do invasor, transformando o estouro em um caso de uso de página após liberação (use-after-free). A página liberada é então reutilizada como uma tabela de páginas de último nível — a condição “Dirty-Pagetable” —, de modo que uma única página física funciona tanto como uma tabela de páginas ativa quanto como uma página que o invasor ainda lê e grava por meio do canal. Um PTE falsificado com auto-aliasing amplia isso para uma ampla operação de leitura/gravação no kernel.

Fuga para o anfitrião. A partir de operações de leitura/gravação no kernel, o PoC contorna o KASLR utilizando a tabela de páginas fixa do SMP-trampoline na memória baixa, sobrescreve as credenciais do processo, altera o caminho de recusa do SELinux na memória e sequestra core_pattern Portanto, um usermodehelper é executado como root nos namespaces iniciais do host. Essa última etapa é a saída.

O arquivo README público documenta essa cadeia, mas omite deliberadamente a estrutura de confiabilidade — o preparo do PCP e o trabalho de cache cruzado que garantem seu funcionamento consistente — e limita o binário fornecido ao EL10, com um requisito de paginação de 5 níveis. Trata-se de uma prova de conceito, não de uma arma pronta para uso. No entanto, há duas consequências importantes para os defensores: após a execução da exploração, getenforce ainda há relatos Enforcing embora a aplicação do SELinux tenha sido enfraquecida e a corrupção ocorra na memória do kernel, e não no disco, de modo que as ferramentas de integridade de arquivos não têm nada a sinalizar.

O que a correção do Upstream altera

A correção consiste em apenas algumas linhas, e é exatamente por isso que é fácil subestimar o problema. Na rota de alocação paginada do IPv6, ela adiciona fraggap para alloclen e subtrai esse valor de pagedlen, de modo que o cabeçalho linear é grande o suficiente para os bytes efetivamente copiados para ele, e a parte paginada se reduz para se adequar a isso. Ele também descarta o agora obsoleto MSG_SPLICE_PAGES exceção na verificação de cópia negativa.

O caminho IPv4 em __ip_append_data() apresentava o mesmo erro contábil e recebe a mesma correção (eca856950f7c). O IPv6 é o caso mais grave e passível de exploração; a versão do IPv4 foi corrigida por uma questão de completude. Como ambas as funções processam caminhos de envio por pacote e não mantêm nenhum estado persistente, a correção é uma forte candidata a um patch que pode ser aplicado quase na íntegra, sem a necessidade de reinicialização.

Quem é afetado

A vulnerabilidade é mais abrangente do que a exploração. A suposição mais segura é que qualquer kernel na faixa de versões 6.6 a 7.1 contenha a falha, a menos que tenha a correção do desenvolvedor original ou um backport de versões posteriores. O PoC público, por outro lado, é propositalmente restrito: ele tem como alvo kernels da família EL10 na versão 6.12.x, requer namespaces de usuário sem privilégios, pressupõe paginação de 5 níveis (LA57) e depende de CONFIG_INIT_ON_ALLOC_DEFAULT_ON estar desligado.

Exploração confirmada – acesso como root no host observado:

• CentOS Stream 10 na versão 6.12.0-242.el10, listado como alvo pelo autor do PoC.
• RHEL 10 na versão 6.12.0-228.el10, também mencionada pelo autor do PoC.
• AlmaLinux 10.2 na versão 6.12.0-211.7.3.el10_2, reproduzido internamente pela KernelCare em 29 de junho de 2026.

Pessoas com risco de exposição: RHEL 10, CentOS Stream 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10 e CloudLinux OS 10 que executam kernels afetados da família EL10 6.12.x sem a correção ou um patch que não exija reinicialização. Essas versões compartilham os pré-requisitos de compilação do RHEL 10, incluindo init_on_alloc desligados; portanto, considere-os expostos, a menos que tenha confirmado o contrário.

A falha existe, mas a técnica pública atual se limita à negação de serviço:

• Ubuntu 24.04 “Noble” (6.8) e Debian 13 “Trixie” (6.12.x). Os testes da KernelCare revelaram que CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y nos kernels enviados, o que zera o ponteiro “stale” inserido e leva a cadeia a um travamento do kernel, em vez de uma fuga da raiz. O PoC também está restrito a um EL10 uname e para o paging de 5 níveis, de modo que não funciona nesses sistemas tal como são fornecidos.

Esse resultado restrito a DoS é específico da técnica atual. O arquivo README indica que uma exploração diferente, que leve em conta o mecanismo “init-on-alloc”, poderá surgir assim que a correção e o CVE forem divulgados. Considere o Ubuntu e o Debian como sistemas vulneráveis, mas que, no momento, não podem ser explorados; não os considere seguros.

Não é afetado por este gatilho:

• Versões do Kernel anteriores à 6.6, nas quais o MSG_SPLICE_PAGES o caminho está ausente e o gatilho retorna -EINVAL.
• Kernels com a fusão 38becddc, correção de IPv6 736b380e28d0, correção de IPv4 eca856950f7c, ou uma adaptação para versões anteriores.

Uma observação: um sistema que simplesmente não atenda às premissas do PoC — como o paging de 4 níveis, por exemplo — não está corrigido. Ele está a salvo desse PoC específico, mas o bug do kernel continua presente em segundo plano.

Aja agora para mitigar

A solução definitiva é um kernel corrigido ou um patch do KernelCare que não requer reinicialização. Até que isso esteja disponível para todos, há duas medidas práticas que podem ser tomadas.

1. Ative o “init-on-alloc” (recomendado no EL10). A exploração pública depende da inserção de um ponteiro inválido na memória slab não inicializada. Zerar a memória na alocação impede essa exploração. Essa opção já vem ativada por padrão no Ubuntu e no Debian; no EL10, ela geralmente está desativada.

Verifique a configuração do kernel, e não a linha de comando de inicialização – isso geralmente é um padrão definido na hora da compilação e não aparecerá em /proc/cmdline:

grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON /boot/config-$(uname -r)   # =y means on

Para ligá-lo quando estiver desligado:

sudo grubby --update-kernel=ALL --args="init_on_alloc=1"
sudo reboot

O custo é uma pequena sobrecarga no alocador. O problema é que é necessário reiniciar o sistema para que a alteração seja aplicada; portanto, isso se encaixa melhor em uma janela de manutenção do que em uma resposta de emergência imediata.

2. Desativar os namespaces de usuários sem privilégios. A cadeia começa a partir de um processo sem privilégios dentro de um contêiner e depende do comportamento dos namespaces sem privilégios. A remoção dessa primitiva interrompe o caminho público, independentemente do estado do alocador.

sysctl user.max_user_namespaces             # check current value
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-ipv6-frag-escape.conf

Isso causa falhas no Podman e no Docker sem privilégios de root, em algumas sandboxes de CI, em sandboxes do tipo Flatpak, no comando `unshare(1)` sem privilégios e em sandboxes de navegadores. Funciona bem em perfis de servidores dedicados, mas causa problemas em hosts de desenvolvedores e de contêineres. Teste antes de implementar em grande escala.

Momento decisivo: Se o servidor não estiver executando nenhum contêiner sem privilégios de root e for possível reiniciá-lo → defina init_on_alloc=1; isso reclassifica o bug como uma falha de sistema, mesmo que a primitiva do usuário retorne posteriormente. Se você não puder reiniciar o sistema, mas puder abrir mão de usuários sem privilégios → desative essa funcionalidade como uma solução provisória sem reinicialização. Se você precisar tanto de contêineres sem privilégios de root quanto de tempo de inatividade zero → o patch sem reinicialização ou um kernel corrigido é a única solução viável, e você deve isolar a execução local não confiável até que uma dessas opções seja implementada.

Patch KernelCare sem reinicialização

Ambos __ip6_append_data() e __ip_append_data() são caminhos de envio por pacote, sem estado persistente de chamadas cruzadas, o que torna a correção aritmética upstream uma adaptação direta do kpatch.

Status do feed (30/06/2026, 09h00 UTC): As compilações do EL10 começaram a ser disponibilizadas no feed de teste para o RHEL 10, Oracle Linux 10, Rocky Linux 10 e AlmaLinux 10.

Aplique a partir do feed de teste após a validação:

sudo kcarectl --update --prefix test

Depois de promovido para o feed principal, ele é exibido na próxima execução programada, ou você pode exibi-lo sob demanda:

sudo kcarectl --update

Verifique se o patch está ativo:

kcarectl --info | grep kpatch-build-time      # build dated 2026-06-30 or later

Assim que um CVE for atribuído, kcarectl --patch-info | grep CVE-2026- também deve disponibilizá-la. Por outro lado, se você estiver gerenciando kernels EL10 diretamente, o AlmaLinux já possui as correções do upstream em seu código-fonte do pacote do kernel (6.12.0-211.28.2) desde 30 de junho — vale a pena ficar de olho em seus repositórios e nas árvores de outros fornecedores para verificar se há erratas correspondentes.

Detecção

Não há nenhuma assinatura clara de pós-exploração para essa classe de vulnerabilidade. A cadeia termina em operações arbitrárias de leitura/gravação no kernel e pode desativar a aplicação do SELinux, enquanto as verificações normais de status ainda parecem tranquilizadoras e nada no disco é alterado. Os sinais que realmente correspondem ao comportamento dessa exploração são comportamentais:

• Mudanças inesperadas em /proc/sys/kernel/core_pattern, especialmente um |- manipulador com o prefixo – o PoC o sobrescreve para executar um usermodehelper como root.
• Um contêiner ou processo filho que trava imediatamente antes de um processo privilegiado incomum ser iniciado no host.
• Lacunas na auditoria do SELinux: a aplicação parece estar ativada, mas as recusas esperadas deixam de aparecer em um host que deveria estar gerando-as.

Auditoria core_pattern e fique atento à sequência de travamento seguida de execução com privilégios. Considere esses sinais como indicativos, e não como prova. Observe que este PoC contorna o KASLR por meio da tabela de páginas fixa do SMP-trampoline, portanto, não precisa ler /proc/kallsyms ou BTF – esses indicadores clássicos de exploração do kernel não aparecerão aqui. Se um usuário ou carga de trabalho não confiável ou parcialmente confiável tiver tido execução local em um host EL10 afetado durante o período de exposição, priorize a aplicação de patches e considere que o host pode exigir uma análise mais aprofundada.

Por que este é importante

O ipv6-frag-escape não envolve execução remota de código e não é um bug do tipo “todas as máquinas Linux param de funcionar instantaneamente”. Para hosts de contêineres, plataformas de hospedagem compartilhada, sistemas de CI, ambientes de teste para desenvolvedores e sistemas Linux multilocatários, a situação é ainda mais grave em um sentido mais específico: ele derruba exatamente a barreira em torno da qual essas plataformas foram construídas. A exploração começa a partir de um processo sem privilégios e termina com acesso de root nos namespaces iniciais do host.

Quando existe uma prova de conceito (PoC) funcional antes de um CVE ou de um backport estável, o fluxo de trabalho habitual de correção baseado em scanners não tem nada que o acione. Os defensores precisam agir diretamente com base nos fatos técnicos. A correção é pequena. A urgência operacional, porém, não é.

Lista de verificação de medidas corretivas priorizadas

1. Aplique a correção — ou a correção que não requer reinicialização — primeiro nos sistemas EL10 afetados, especialmente nos hosts de contêineres e em qualquer lugar onde código não confiável ou semiconfiável possa ser executado.
2. Ativar init_on_alloc=1 nos casos em que um kernel fixo ou um patch que não exija reinicialização ainda não tenha sido implantado.
3. Desative os espaços de nomes de usuários sem privilégios nos casos em que a carga de trabalho permitir.
4. Considere o Ubuntu 24.04 e o Debian 13 como “com falhas, sem acesso às técnicas públicas atuais”, e não como seguros.
5. Auditoria core_pattern e as atividades de bloqueio do SELinux em hosts expostos.
6. Fique atento à atribuição de CVEs e às errata dos fornecedores a jusante, e reavalie os sistemas assim que forem implementadas backports estáveis — mesmo que o PoC público nunca tenha sido executado em seu ambiente.

Referências

• PoC público: https://github.com/sgkdev/ipv6_frag_escape
• Correção de fusão no upstream (7.2-rc1): https://github.com/torvalds/linux/commit/38becddc332c1dbee6ab8dc8f13a860c6280b905
• Correção do IPv6 736b380e28d0; Correção de IPv4 eca856950f7c; ativação do gatilho ce650a166335; que introduz erros 773ba4fe9104 (IPv6) / 8eb77cc73977 (IPv4)
• Backport do pacote do kernel do AlmaLinux (6.12.0-211.28.2): Servidor Git do sistema operacional AlmaLinux, commit 674503c679

Aplique patches em qualquer kernel, sem necessidade de reinicialização. Se você ainda não é usuário do KernelCare, este é um bom momento para descobrir como a aplicação de patches sem reinicialização protege sistemas Linux críticos, sem a necessidade de janelas de manutenção de emergência ou tempo de inatividade.

Adquira o KernelCare hoje mesmo →