Uma vulnerabilidade de condição de corrida no sistema de arquivos XFS do kernel Linux, identificada como
CVE-2026-64600
, permite que invasores locais sobrescrevam arquivos protegidos e obtenham privilégios de root.
Batizada de RefluXFS pela Qualys Threat Research Unit (TRU), que descobriu e reportou a falha, a vulnerabilidade afeta sistemas com XFS e reflink habilitado — configuração padrão em grandes distribuições Linux corporativas, executando Linux kernel v4.11 ou posterior, com um diretório gravável por um usuário local sem privilégios e um alvo de alto valor, como um arquivo de configuração pertencente ao root ou um binário SUID-root.
Segundo a Qualys, instalações padrão de Red Hat Enterprise Linux e suas derivadas, Fedora Server e Amazon Linux podem atender às condições necessárias para a exploração. A empresa demonstrou a corrida contra o arquivo /etc/passwd e binários setuid-root, e afirma que a exploração é altamente confiável, não deixa saída no log do kernel e mantém a modificação no disco mesmo após a reinicialização do sistema.
A sobrescrita acontece na camada de blocos, abaixo do nível em que atuam as defesas padrão. SELinux, kernel lockdown, mecanismos de isolamento de contêineres e recursos de proteção de memória como KASLR, SMEP e SMAP não impedem os ataques RefluXFS porque a falha opera na camada de alocação do sistema de arquivos. Como o ataque contorna o inode do alvo, os metadados nunca mudam, e os pesquisadores disseram que seus testes não geraram alerta do kernel nem entrada em log.
“O invasor clona o arquivo-alvo com reflink, por exemplo /etc/passwd ou um binário SUID-root como /usr/bin/su, para um arquivo temporário de sua propriedade e, em seguida, provoca uma condição de corrida com gravações O_DIRECT simultâneas nesse arquivo”, explica a equipe da Qualys TRU em um relatório técnico detalhado publicado na quarta-feira. “Uma janela de queda de bloqueio no caminho de alocação copy-on-write do kernel permite que uma dessas gravações chegue, não ao armazenamento do atacante, mas ao bloco físico que ainda sustenta o arquivo original. A alteração é feita diretamente no disco, persiste após a reinicialização, não produz saída no log do kernel e não toca o inode do arquivo-alvo, de modo que um binário SUID-root modificado mantém o bit SUID.”
A RefluXFS existe desde a versão 4.11 do kernel, após ter sido introduzida em fevereiro de 2017 pelo commit 3c68d44a2b49. Ela está presente em todos os kernels mainline e estáveis desde então e recebeu correção em 16 de julho, depois que o commit 2f4acd0 foi incorporado à árvore de código-fonte do Linux. O patch relaciona o bug ao Linux 4.11 por meio de uma marca Fixes: que cita o commit 3c68d44a2b49 e de uma solicitação de backport para a versão estável marcada como # v4.11.
A exploração exige três condições: o sistema executa Linux 4.11 ou posterior sem a correção do RefluXFS, o sistema de arquivos XFS foi criado com reflink=1 e o arquivo legível e um diretório gravável pelo atacante estão no mesmo sistema de arquivos XFS. Verifique o sistema de arquivos raiz com `xfs_info / | grep reflink=`; reflink=1 significa que a segunda condição foi atendida. Faça a mesma checagem em qualquer outro volume XFS montado em que um arquivo protegido e um diretório gravável pelo atacante compartilhem o mesmo sistema de arquivos.
A Qualys disse que a prioridade deve ser a correção de sistemas expostos e multi-inquilino, o que inclui qualquer host XFS com reflink habilitado em que código não confiável possa ser executado localmente, seja por meio de um shell, de um job de CI ou de um serviço comprometido. A empresa estima que a falha possa afetar mais de 16,4 milhões de sistemas com base em análises feitas com seu software Cybersecurity Asset Management.
O alerta lista as instalações padrão que podem atender a essas condições: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux e CloudLinux 8, 9 e 10, Fedora Server 31 e posteriores, Amazon Linux 2023 e imagens do Amazon Linux 2 a partir de dezembro de 2022. Os sistemas de arquivos do RHEL 7 não são afetados porque antecedem o suporte ao reflink no XFS.
Debian, Ubuntu, SLES e openSUSE geralmente não usam XFS no sistema de arquivos raiz por padrão. Nessas distribuições, a exposição ocorre apenas se o administrador tiver escolhido XFS com reflink habilitado durante a instalação. O rastreador do Debian registrava até 23 de julho a correção em trixie-security como kernel 6.12.96-1 e em unstable como 7.1.4-1; o kernel base do trixie, 6.12.94-1, e o do forky, 7.1.3-1, ainda apareciam como vulneráveis, assim como bookworm e bullseye, incluindo seus ramos de segurança.
O mapeamento obsoleto
O atacante clona um arquivo pertencente ao root para um arquivo temporário com FICLONE, o que exige apenas permissão de leitura sobre o arquivo de origem, e então disputa escritas O_DIRECT concorrentes contra o clone. Os reflinks do XFS usam cópia na gravação, então os dois arquivos inicialmente apontam para os mesmos blocos físicos no disco.
O kernel lê o mapeamento do data fork sob o bloqueio do inode e o entrega a xfs_reflink_fill_cow_hole(), que libera esse bloqueio para reservar espaço de transação. Um segundo escritor pode concluir a operação de cópia na gravação durante essa janela e remapear o arquivo clonado para um novo bloco. Quando o primeiro escritor readquire o bloqueio, ele atualiza o fork de cópia na gravação, mas continua usando o mapeamento antigo do data fork.
O patch do projeto upstream descreve a falha de forma direta: “the mappings are stale as soon as we reacquire the ILOCK”. Esse endereço obsoleto passa a apontar para um bloco pertencente somente ao arquivo protegido original. O XFS entende que o bloco não está mais compartilhado e permite a escrita direta, de modo que os dados destinados ao clone do atacante acabam gravados no alvo.
Trata-se de um erro de verificação antes do uso, atravessando um ciclo de bloqueio. A consulta sobre o status de compartilhamento é correta; o problema é que ela usa um endereço de bloco capturado antes de o bloqueio ser liberado. Segundo o The Hacker News, o patch afeta duas funções auxiliares, xfs_reflink_fill_cow_hole() e xfs_reflink_fill_delalloc(). A segunda segue o mesmo padrão de ciclo de bloqueio e não aparece no alerta da Qualys.
Em ambas, a correção salva ip->i_df.if_seq antes de o bloqueio ser liberado e relê o data fork com xfs_bmapi_read() se o contador tiver mudado. O Direct I/O ignora o cache de páginas e não tem gancho de revalidação, então a gravação chega ao disco. Na máquina de teste, a corrida costumava ser vencida em menos de 10 segundos, e a demonstração publicada remove a senha de root em uma instalação padrão do RHEL 10.2.
A Qualys afirmou que um modelo de IA encontrou a falha. A empresa apontou o Claude Mythos Preview, modelo de fronteira com acesso restrito da Anthropic, para o kernel e, segundo seu alerta técnico, pediu que ele encontrasse uma vulnerabilidade semelhante ao Dirty COW. Saeed Abbasi, chefe da Threat Research Unit da Qualys, afirmou que a descoberta surgiu de uma iniciativa de pesquisa entre a Qualys e a Anthropic, na qual pesquisadores integraram o modelo de IA ao fluxo manual de auditoria.
O modelo localizou a corrida, escreveu um exploit funcional para obter root e redigiu o alerta. Em seguida, os pesquisadores reproduziram o problema em uma instalação padrão do Fedora Server 44, validaram o raciocínio do modelo e coordenaram a divulgação com o projeto upstream.
“A aplicação imediata do patch do kernel é recomendada para neutralizar essa vulnerabilidade. A exploração ocorre de forma consistente sob configurações padrão de endurecimento, e a modificação no disco sobrevive à reinicialização do sistema”, disse Abbasi. “Já existem kernels corrigidos pelos fornecedores, e eles estão sendo levados por backport para distribuições corporativas. As organizações devem priorizar a aplicação de patch em sistemas expostos e multi-tenant e garantir uma reinicialização para verificar a atualização. Até o momento, não há mitigações confiáveis ou práticas nem mudanças temporárias de configuração disponíveis.”
A Red Hat emitiu alertas de kernel classificados como Importante para os fluxos afetados do RHEL 8, 9 e 10. As correções começaram a ser disponibilizadas em 14 de julho, oito dias antes da divulgação coordenada: RHSA-2026:39179 e RHSA-2026:39180 para o RHEL 8 e RHSA-2026:39494 para o RHEL 10, com os fluxos de suporte estendido e SAP seguindo até 17 de julho. A cobertura varia conforme o fluxo, então confirme se existe um alerta para a sua versão exata.
Quem aplicou essas correções no prazo já estava protegido antes de o RefluXFS receber esse nome. Verifique as datas dos seus patches antes de presumir exposição. O rastreador de bugs do fornecedor registra a falha sob o título “kernel: XFS data corruption using reflink”. O registro foi importado automaticamente em 10 de julho e inicialmente descrevia o problema como possível corrupção de dados ao usar reflink em um arquivo.
A Qualys não publicou código de exploit independente. O rastreador da Red Hat registrou em 22 de julho uma prova de conceito pública, apontando para o alerta publicado na lista oss-security, que descreve a corrida e os passos de exploração em detalhes. Até o momento da publicação, nenhum dos fornecedores que acompanham a falha havia relatado exploração em ambiente real.
Instalar o pacote não substitui o kernel que já está carregado na memória. Aplique a atualização do fornecedor, reinicie o sistema e verifique se ele está executando o kernel corrigido.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...