A vulnerabilidade CVE-2026-64600, presente no código há nove anos, explora uma condição de corrida no sistema de arquivos XFS para permitir que usuários locais sobrescrevam arquivos do root e obtenham persistência.
| Componente | Kernel Linux (sistema de arquivos XFS com suporte a reflink) |
| Vetor | Condição de corrida na função xfs_reflink_fill_cow_hole após clonagem de arquivos via FICLONE, combinada com escritas O_DIRECT concorrentes |
| Impacto | Sobrescrita de arquivos binários setuid-root ou configurações críticas sem alteração de metadados, permitindo escalonamento para root e persistência |
| Prioridade | Aplicação imediata de correções de kernel fornecidas pelos fornecedores e reinicialização do sistema |
Uma nova vulnerabilidade de alta gravidade no kernel Linux, apelidada de RefluXFS e rastreada como CVE-2026-64600, permite que um usuário local não privilegiado sobrescreva arquivos de propriedade do root em um sistema de arquivos XFS, resultando em escalonamento de privilégios e acesso persistente. A falha originates de um problema introduzido em 2017, a partir do kernel 4.11, e afeta especificamente a implementação de recursos de copy-on-write (reflink) do XFS. Pesquisadores demonstraram que a exploração é viável em instalações padrão de distribuições como Red Hat Enterprise Linux (RHEL), Fedora Server e Amazon Linux, onde as condições para o ataque são frequentemente atendidas por padrão sem configurações adicionais.
O mecanismo da falha reside em uma condição de corrida (race condition) que ocorre no nível da camada de bloco. Ao manipular a forma como o kernel XFS gerencia o compartilhamento de blocos físicos entre arquivos clonados, um atacante pode redirecionar operações de escrita direta (O_DIRECT) destinadas a um arquivo sob seu controle para blocos de disco que pertencem a arquivos protegidos do root. O aspecto crítico desse problema é que a sobrescrita ocorre de forma a preservar os metadados originais do arquivo alvo, incluindo propriedade, permissões, carimbos de tempo e o bit setuid. Isso significa que um binário setuid-root modificado continuará executando como root, mascarando a intrusão e garantindo acesso elevado persistente através de reinicializações do sistema.
A exploração da vulnerabilidade RefluXFS começa com o requisito de que o arquivo alvo legível pelo root e um diretório gravável pelo atacante residam no mesmo sistema de arquivos XFS com a opção reflink habilitada. O atacante executa a chamada de sistema FICLONE para criar um clone (copiado sob demanda) de um arquivo proprietário do root. Como o clone é inicialmente um ponteiro para os mesmos blocos físicos do original, o atacante precisa apenas de permissão de leitura no arquivo de origem para criar a cópia. Em seguida, o atacante inicia uma corrida contra o mecanismo de copy-on-write do kernel, disparando escritas diretas (O_DIRECT) no arquivo clonado.
A falha técnica concreta está dentro da função xfs_reflink_fill_cow_hole. Durante o processamento da escrita, o kernel lê o mapeamento do fork de dados sob o bloqueio do inode (ILOCK) e, em seguida, libera esse bloqueio temporariamente para reservar espaço de transação. Nesse intervalo, ocorre a condição de corrida. Se um segundo escritor completar a operação de copy-on-write e remapear o arquivo clonado para um novo bloco físico enquanto o bloqueio está liberado, o primeiro escritor, ao readquirir o bloqueio, atualiza o fork de copy-on-write, mas permanece utilizando o mapeamento obsoleto do fork de dados capturado anteriormente.
Esse endereço obsoleto agora aponta para um bloco de propriedade exclusiva do arquivo original protegido. Como o XFS vê o bloco como não compartilhado devido à lógica defeituosa de validação, ele permite que a escrita direta prossiga. Consequentemente, os dados destinados ao clone do atacante são gravados fisicamente no bloco do arquivo alvo do root. Trata-se de um erro verificado-e-usado (check-then-use) através de um ciclo de bloqueio, onde a consulta de status compartilhado estava correta no momento da verificação, mas o endereço do bloco consultado já não era válido quando utilizado.
A falha afeta sistemas que executam o kernel Linux versão 4.11 ou posterior, lançado em 2017, que não possuem o patch para o RefluXFS aplicado. Distribuições que utilizam o XFS como sistema de arquivos padrão para o particionamento raiz com suporte a reflink são particularmente vulneráveis. Isso inclui instalações padrão do Red Hat Enterprise Linux e seus derivados como CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux e CloudLinux nas versões 8, 9 e 10. O Amazon Linux 2023 e as imagens do Amazon Linux 2 a partir de dezembro de 2022 também estão expostos. Instalações do Fedora Server 31 e posteriores são suscetíveis. Sistemas de arquivos do RHEL 7 não são afetados porque antecedem o suporte a reflink no XFS.
Outras distribuições, como Debian, Ubuntu, SLES e openSUSE, geralmente não utilizam XFS para o sistema de arquivos raiz por padrão, o que reduz a exposição imediata. No entanto, elas permanecem vulneráveis se um administrador escolheu explicitamente o XFS com a opção reflink habilitada durante o processo de instalação. A condição de exploração é satisfeita se o sistema de arquivos montado estiver configurado com reflink=1. É possível verificar essa condição em qualquer volume XFS montado onde um arquivo protegido e um diretório gravável por um usuário não confiável coexistam.
- Red Hat Enterprise Linux e derivados (versões 8, 9 e 10)
- Fedora Server 31 e versões posteriores
- Amazon Linux 2023 e Amazon Linux 2 (imagens a partir de dezembro de 2022)
- Debian, Ubuntu e SLES apenas se XFS com reflink foi configurado manualmente
A detecção de tentativas de exploração da RefluXFS desafia a telemetria tradicional de segurança, pois a operação de gravação ocorre na camada de bloco ignorando o inode do alvo. Consequentemente, a escrita não altera os metadados do arquivo alvo e, em testes, não produziu avisos ou entradas de log do kernel. Defensores devem priorizar a verificação da integridade de arquivos binários setuid-root críticos e arquivos de configuração sensíveis, procurando por discrepâncias entre o conteúdo do arquivo e seus hashes assinados ou conhecidos. A modificação de um binário setuid-root que retém seu bit setuid e proprietário original é um indicador forte de comprometimento.
A triagem de sistemas deve incluir a verificação da versão do kernel em execução em relação aos avisos de segurança emitidos pelos fornecedores. Para ambientes RHEL, a presença dos avisos RHSA-2026:39179, RHSA-2026:39180 e RHSA-2026:39494 indica que a correção está disponível para o respectivo fluxo (stream). Equipes de segurança devem auditar sistemas para identificar se o sistema de arquivos raiz é XFS e suporta clonagem. Embora não haja um log direto da condição de corrida, um aumento anômalo de operações de E/S direta (O_DIRECT) em sistemas usuários onde não é esperado, ou a clonagem frequente de arquivos do sistema via FICLONE por processos não administrativos, pode servir como sinal de alerta tático para investigação forense.
- Verificar integridade de binários setuid-root em busca de modificações sem alteração de metadados
- Confirmar versão do kernel contra boletins de segurança do fornecedor (ex: RHSA-2026:39494)
- Auditar pontos de montagem para identificar sistemas de arquivos XFS com suporte a reflink ativado
- Monitorar por uso anômalo de chamadas de sistema FICLONE e escritas O_DIRECT por processos não privilegiados
A única mitigação eficaz para a vulnerabilidade RefluXFS é a aplicação da correção do kernel fornecida pelos fornecedores e a reinicialização subsequente do sistema para carregar o núcleo atualizado. O patch foi mesclado upstream em 16 de julho e os fornecedores começaram a distribuir kernels com backport da correção. Não existe opção de montagem ou parâmetro sysctl que desabilite os reflinks do XFS após o sistema de arquivos ter sido criado, e mudanças de configuração temporárias não são praticáveis.
Medidas de segurança em nível de aplicação e contêiner, como SELinux em modo Enforcing, seccomp, bloqueio do kernel (lockdown) e limites de contêiner, não impedem a exploração nos testes realizados. Proteções de memória como KASLR e SMEP também não se aplicam, pois o problema é uma escrita na camada de bloco e não uma corrupção de memória. A instalação do pacote de atualização não substitui o kernel em execução na memória; portanto, a reinicialização é um passo obrigatório para garantir que o sistema não esteja mais vulnerável. Administradores devem priorizar a atualização de sistemas expostos e multi-tenant, onde código não confiável pode ser executado localmente via shell, trabalhos de CI ou serviços comprometidos.
- Aplicar atualizações de kernel que incluam o patch para CVE-2026-64600
- Reiniciar o sistema para carregar o kernel corrigido e limpar a memória vulnerável
- Priorizar patching em ambientes multi-tenant e允许 execução de código não confiável localmente
- Monitorar boletins de fornecedores para confirmar a disponibilidade de correção para versões específicas do sistema
0 Comentários