Nova falha no RefluXFS para Linux resiste às reinicializações e não é registrada nos logs

Ao vivo esta tarde: vamos analisar a vulnerabilidade RefluXFS com um especialista em patches para Linux, incluindo as últimas atualizações dos fornecedores e como corrigir a vulnerabilidade sem precisar reiniciar o sistema. Assista aqui →

A versão resumida

Ir para a versão completa ↓

O que é: O RefluXFS, registrado como CVE-2026-64600, é uma condição de corrida no caminho de “copy-on-write” do sistema de arquivos XFS do kernel do Linux. Ele permite que um usuário local sem privilégios redirecione uma gravação de uma cópia com link simbólico de volta para o bloco físico do disco do arquivo original, de modo que um invasor possa alterar um arquivo de propriedade do usuário root que ele tem permissão para ler, mas não para gravar. Ir para a versão completa →

Impacto: Escalada de privilégios locais para root. A Qualys demonstrou isso em relação ao arquivo /etc/passwd e aos binários setuid-root em um sistema Linux empresarial padrão, removendo a proteção por senha da conta root em um sistema RHEL 10.2 padrão em questão de segundos. A gravação ocorre abaixo do caminho normal de gravação do inode, de modo que consegue preservar o proprietário, as permissões, os carimbos de data/hora e o bit setuid do alvo, sobrevive a uma reinicialização e não gerou nenhuma saída no log do kernel nos testes da Qualys. Ir para a versão completa →

Gravidade: Nenhuma pontuação CVSS pública havia sido confirmada até o momento da redação deste artigo. Considere-a, de qualquer forma, como alta prioridade: a exploração é confiável, requer apenas uma conta local comum, contorna medidas comuns de fortificação e concede acesso root persistente. A Red Hat classifica-a como “Importante”. Ir para a versão completa →

Quem está afetado: kernels do Linux baseados na versão 4.11 ou posterior que contenham o código XFS vulnerável e não possuam a correção, em um sistema de arquivos XFS criado com suporte a reflink, no qual um arquivo protegido para leitura e um diretório no qual um invasor possa gravar compartilhem esse sistema de arquivos. Isso descreve a configuração padrão no RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux e CloudLinux 8, 9 e 10, além do Fedora Server 31 e versões posteriores, do Amazon Linux 2023 e das imagens do Amazon Linux 2 a partir de dezembro de 2022. O RHEL 7 é anterior ao reflink do XFS e está fora da exposição padrão. Ir para a versão completa →

Status: Divulgado publicamente pela Qualys em 22 de julho de 2026 e identificado com o auxílio de IA no âmbito do Projeto Glasswing, da Anthropic. A correção de código-fonte foi incorporada em 16 de julho, e os fornecedores já lançaram kernels com a correção retroativa. Algumas correções corporativas foram lançadas antes da divulgação como atualizações comuns do kernel; portanto, um host pode já conter a correção, mesmo que a atualização nunca tenha mencionado o CVE-2026-64600. Ir para a versão completa →

Faça isso agora: não há nenhuma solução alternativa de configuração isenta de riscos. A Red Hat publicou uma medida de mitigação temporária via SystemTap, mas a correção definitiva é um kernel corrigido: verifique se cada sistema de arquivos XFS utiliza reflinks, aplique o kernel corrigido específico para a sua versão e reinicie o sistema, ou aplique um patch do KernelCare que não requer reinicialização (que é implantado automaticamente para os usuários em segundo plano). Ir para a versão completa →

xfs_info / | grep reflink=

Um resultado de `reflink=1` confirma o pré-requisito do sistema de arquivos. Repita o procedimento para outros volumes XFS montados que contenham tanto arquivos protegidos quanto diretórios nos quais um invasor possa gravar.

O RefluXFS quebra uma das promessas mais básicas do sistema de arquivos: a de que ter permissão para ler um arquivo protegido não significa que você possa reescrevê-lo.

O invasor nunca abre o arquivo /etc/passwd ou um binário com setuid-root para gravação. O Linux impediria isso imediatamente. Em vez disso, ele solicita ao XFS que crie uma cópia com link simbólico do arquivo em algum local sob seu controle e, em seguida, realiza duas gravações simultâneas nessa cópia. Devido a um mapeamento de bloco desatualizado dentro do kernel, uma dessas gravações pode acabar sendo aplicada ao arquivo original protegido, em vez de à cópia. O invasor grava em um arquivo sob seu controle, mas o arquivo original, de propriedade do usuário root, é alterado.

Essa única vulnerabilidade é suficiente para apagar a senha de root, reescrever dados de autenticação ou inserir código malicioso em um binário setuid-root para que ele seja executado como root. Em uma instalação padrão do RHEL 10.2, a Qualys conseguiu fazer isso em segundos.

Vale a pena dar uma pausa para analisar um detalhe, especialmente no que diz respeito à discussão transmitida ao vivo. O RefluXFS foi encontrado no âmbito do Projeto Glasswing, da Anthropic: a Qualys indicou ao Claude Mythos Preview o kernel e solicitou que ele procurasse por uma condição de corrida do tipo Dirty COW; em seguida, seus próprios pesquisadores reproduziram a descoberta, verificaram todas as alegações e realizaram a divulgação coordenada. A IA acelerou a busca; os humanos confirmaram e divulgaram a descoberta. Encare isso como uma prévia do rumo que a detecção de bugs no kernel está tomando, e não como uma exploração do tipo “apertar um botão”.

Duas coisas ainda vão levá-lo a classificar isso como um problema de baixa gravidade. A primeira é a formulação da atualização original do fornecedor, que foi lançada simplesmente como uma correção para “corrupção de dados no XFS” e soa como um incômodo relacionado à integridade dos dados. Trata-se de uma primitiva de raiz local confiável. A segunda é o próprio reflink, que parece uma opção exótica que ninguém habilita. Ele tem sido o padrão do mkfs no sistema de arquivos raiz da família RHEL há anos; portanto, em um sistema padrão, você já atende à condição sem precisar perguntar.

Os links de referência do XFS permitem que dois arquivos apontem para os mesmos blocos físicos do disco sem duplicar os dados. Quando um arquivo é gravado, o XFS executa a operação “copy-on-write”: ele aloca um novo bloco para o arquivo alterado, copia os dados, remapeia esse arquivo e reduz a contagem de referências do bloco original. O arquivo original deve permanecer inalterado.

O RefluXFS é o que ocorre quando duas gravações competem por essa sequência.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

O código vulnerável lê o fork de dados do arquivo sob o bloqueio do inode e, em seguida, libera o bloqueio para reservar espaço no log de transações. Durante esse intervalo, um segundo gravador pode concluir seu próprio ciclo de “copy-on-write”, remapear o clone para um bloco novo e reduzir a contagem de referências do bloco original para um. Quando o primeiro gravador readquire o bloqueio, ele verifica novamente se o bloco ainda está compartilhado, mas faz a verificação com base no endereço físico que capturou antes de o bloqueio ser liberado. Esse endereço é um mapeamento desatualizado da bifurcação de dados. O XFS vê uma contagem de um, conclui que o bloco é privado e grava nele, mesmo que esse bloco agora pertença apenas ao arquivo de origem protegido.

Como o O_DIRECT ignora o cache de páginas, não há revalidação e a gravação vai para o disco. Trata-se de uma corrida entre o momento da verificação e o momento do uso, ao longo de um ciclo de bloqueio de inode. A verificação de permissão nunca esteve errada. O kernel simplesmente agiu com base em um endereço de bloco que já estava desatualizado.

A correção faz com que o XFS releia o mapeamento do data-fork após detectar que o mapeamento pode ter sido alterado enquanto o bloqueio estava liberado:

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

O artigo da Qualys identifica a perda do bloqueio na função xfs_reflink_allocate_cow(). O commit da linha principal, intitulado “xfs: reamostrar o mapeamento do data fork após o ciclo do ILOCK”, foi incorporado em 16 de julho e reamostra o mapeamento nos auxiliares CoW afetados. Ele não altera nenhum formato no disco nem o layout das estruturas de dados do kernel, o que será importante posteriormente para a aplicação de patches sem reinicialização.

A sobrescrita ocorre na camada de blocos e ignora o caminho normal de gravação no nível do inode do arquivo protegido. Isso anula vários sinais comumente usados para a detecção de alterações em arquivos:

• O destino mantém seu proprietário original e seu modo de permissão.
• O bit setuid permanece ativo; portanto, um binário setuid-root adulterado ainda é executado como root.
• Seus carimbos de data e hora não precisam refletir a alteração.
• O monitoramento de atividades em arquivos com base no caminho pode não registrar uma gravação no próprio destino protegido.
• Os dados modificados permanecem no disco após uma reinicialização.
• A Qualys não observou nenhum aviso no kernel nem nenhuma entrada de log correspondente.

É por isso que o RefluXFS é pior do que um bug transitório de corrupção de memória. Trata-se de uma primitiva de modificação persistente no disco que deixa intactos a maioria dos sinais que os defensores esperam detectar. Uma ferramenta de integridade de arquivos que calcula o hash do conteúdo dos arquivos ainda pode detectá-lo. Ferramentas que se baseiam em metadados, registros de auditoria baseados em caminhos ou avisos do kernel não conseguirão.

É necessário que todas as três condições sejam satisfeitas:

1. O sistema executa um kernel do Linux vulnerável, baseado na versão 4.11 ou posterior, sem a correção.
2. O sistema de arquivos XFS em questão foi criado com suporte a reflinks.
3. Um destino protegido para leitura e um diretório no qual o invasor pode gravar estão localizados nesse mesmo sistema de arquivos.

Verifique o sistema de arquivos raiz e todos os volumes XFS montados nos quais código local não confiável possa ser executado, já que um volume de dados separado pode ficar exposto mesmo quando o raiz não estiver:

xfs_info / | grep reflink=

Uma saída contendo “reflink=1” significa que o pré-requisito do sistema de arquivos está presente.

A Qualys lista o RHEL, o CentOS Stream, o Oracle Linux, o Rocky Linux, o AlmaLinux e o CloudLinux 8, 9 e 10 entre as distribuições corporativas mais comumente afetadas, juntamente com o Fedora Server 31 e versões posteriores, o Amazon Linux 2023 e as AMIs do Amazon Linux 2 lançadas a partir de dezembro de 2022.

O Debian, o Ubuntu, o SLES, o openSUSE e o Fedora Workstation não utilizam o XFS como sistema de arquivos raiz por padrão, e só ficam expostos se um administrador optar pelo XFS com o reflink habilitado. Os sistemas de arquivos do RHEL 7 são anteriores ao suporte ao reflink do XFS e estão fora do escopo da exposição padrão descrita aqui.

Não tente chegar à “segurança” por meio de raciocínios. A corrida só é acionada quando o bloco-alvo está inicialmente não compartilhado, o que leva à suposição de que um arquivo que você já copiou com reflink estaria imune; no entanto, um usuário sem privilégios pode redefinir esse estado, e é improvável que binários com setuid-root tenham sido copiados com reflink desde o início. Essa restrição aparente não oferece um limite de segurança confiável.

Nossa equipe do kernel reproduziu a vulnerabilidade nas seguintes compilações e verificou que as compilações correspondentes dos fornecedores contêm a correção:

Trata-se de versões pontuais específicas. A cobertura é específica para cada stream; portanto, verifique o aviso referente à sua versão exata, em vez de partir de suposições com base em uma versão próxima.

Os layouts padrão do Enterprise Linux facilitam a exploração

A exigência de que os arquivos estejam no mesmo sistema de arquivos parece restritiva. Em uma instalação corporativa típica, porém, isso não é o caso, pois o layout padrão do XFS com raiz única coloca tudo isso em um único volume:

• Executáveis de propriedade do usuário root na pasta /usr/bin
• Dados de autenticação na pasta /etc
• A pasta /tmp com permissão de gravação para todos
• Diretórios pessoais dos usuários na pasta /home

Isso concede a um usuário sem privilégios tanto alvos de alto valor legíveis quanto espaço temporário gravável no mesmo sistema de arquivos habilitado para reflink. Imagine os ambientes em que isso pode ocorrer: um host de compilação compartilhado, um executor de CI executando o que quer que tenha sido enviado na última solicitação de mesclagem, um nó multilocatário onde cargas de trabalho em contêineres ou restritas podem acessar caminhos adequados no mesmo sistema de arquivos XFS do host, uma máquina de desenvolvedor executando dependências não confiáveis. Em cada um desses casos, uma conta comum é tudo o que a exploração precisa.

Trata-se de uma escalada de privilégios local no host, não de execução remota de código nem de uma fuga do convidado para o hipervisor. Um invasor precisa, primeiro, obter execução local de código. Assim que consegue isso, o RefluXFS transforma esse ponto de apoio em acesso root no host.

Por que as medidas comuns de fortalecimento do Linux não impedem isso

O RefluXFS não é uma vulnerabilidade convencional que causa corrupção na memória do kernel. Ele se aproveita de operações normais do sistema de arquivos para direcionar uma gravação para o bloco físico errado, e é por isso que muitas defesas comuns não o detectam:

• SELinux: A Qualys reproduziu a exploração com o SELinux no modo Enforcing.
• KASLR, SMEP e SMAP: esses mecanismos protegem contra caminhos de corrupção de memória, e não contra a alocação de blocos no sistema de arquivos; portanto, eles nunca são acionados.
• Bloqueio do kernel: não impõe nenhuma restrição às operações comuns de reflink ou de E/S direta para usuários sem privilégios.
• Contêineres e namespaces: eles não bloqueiam automaticamente o acesso ao caminho vulnerável do sistema de arquivos.
• Seccomp: os perfis típicos permitem as operações comuns com arquivos que o ataque utiliza.
• Reinicialização sem atualização: o arquivo corrompido permanece, e a inicialização do mesmo kernel vulnerável mantém a falha ativa.

Não são necessários recursos especiais. Não é necessário CAP_SYS_ADMIN, nem namespace privilegiado, nem hardware incomum, nem configuração personalizada do kernel. Os pré-requisitos relacionados ao XFS, ao reflink e ao mesmo sistema de arquivos ainda se aplicam, mas já estão presentes por padrão em muitas instalações corporativas do Linux afetadas.

Não há nenhuma solução alternativa de configuração isenta de riscos, mas a Red Hat publicou uma medida de mitigação temporária em tempo de execução.

A opção reflink é selecionada quando o sistema de arquivos XFS é criado. Não há nenhuma opção de montagem nem configuração sysctl que converta um sistema de arquivos existente com reflink=1 em um sem reflink, e recriar o sistema de arquivos não é uma solução de emergência para ambientes de produção. Remover os bits setuid do su, do sudo ou do pkexec interrompe o funcionamento normal e não é uma correção adequada.

A equipe de Segurança de Produtos da Red Hat publicou uma medida de mitigação provisória para o SystemTap que intercepta o ponto de entrada do reflink no XFS e força as operações de reflink a retornarem um erro de operação não suportada. É possível adotar uma abordagem semelhante com kprobes. Isso bloqueia o caminho vulnerável do reflink, mas altera o comportamento do sistema de arquivos e pode afetar aplicativos que dependem da clonagem via reflink; portanto, valide-a primeiro em um ambiente de teste. Trate-a como uma proteção temporária para sistemas que não podem receber o patch imediatamente, e não como um substituto para um kernel corrigido.

A verdadeira solução é um kernel corrigido, quer o sistema seja reiniciado ou não.

A instalação de um pacote do kernel não altera o kernel que já está em execução na memória. Para uma atualização convencional do fornecedor: instale a atualização do kernel específica para a sua versão, reinicie o sistema e confirme se ele inicializou com essa versão.

uname -r

Para os streams específicos listados acima, as compilações fixas testadas são 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8 e 6.12.0-211.34.1.el10_2. Verifique se o kernel em execução corresponde ao aviso de segurança referente à sua distribuição, stream e arquitetura exatas.

Há duas armadilhas a serem evitadas. Não se baseie no pacote mais recente no disco; baseie-se no kernel em execução. E não presuma que todos os kernels compilados após 16 de julho contenham a correção, pois os números de versão das distribuições não correspondem às versões do upstream e algumas ramificações já haviam feito o backport dessa correção anteriormente. Verifique o comunicado do fornecedor referente à ramificação específica. Como alguns fornecedores lançaram a correção antes que o CVE fosse divulgado publicamente, os scanners baseados em CVE podem não fornecer uma visão completa do histórico de patches.

Aplicação de patches sem reinicialização

O RefluXFS é adequado para a aplicação de patches sem reinicialização. A correção consiste em uma alteração específica na forma como o código do XFS atualiza o mapeamento de blocos após o ciclo do bloqueio do inode, sem alteração no formato do disco e sem substituição da estrutura de dados do kernel em todo o sistema.

O comunicado público da Qualys recomenda a instalação de um kernel corrigido e a reinicialização do sistema, e observa corretamente que o reflink não pode ser desativado em um sistema de arquivos ativo existente.

O KernelCare adota uma abordagem diferente para a correção: ele aplica a correção do código XFS subjacente diretamente ao kernel em execução, em vez de tentar desativar o reflink ou alterar a configuração do sistema de arquivos.

A rota vulnerável do CoW, então, reamostra o mapeamento da bifurcação de dados após o ciclo de bloqueio, sem uma janela de manutenção ou reinício da carga de trabalho. Trata-se de um bug exclusivo do kernel, sem nenhum componente de biblioteca do espaço do usuário a ser investigado.

Os usuários do KernelCare geralmente configuram os patches de forma que todas as novas correções sejam implantadas automaticamente, em segundo plano, em intervalos específicos — como a cada 4 horas, por exemplo. No entanto, os usuários também podem aplicar qualquer patch do feed de produção assim que ele for promovido:

kcarectl --update

Confirme o mapeamento do CVE em vez de confiar na data de compilação, já que um kernel compilado após meados de julho não inclui automaticamente essa correção:

kcarectl --patch-info | grep 'CVE-2026-64600'

Caso um patch ainda esteja sendo divulgado por meio do canal de testes da sua família de kernels, confirme a disponibilidade antes de contar com a cobertura sem reinicialização e, enquanto isso, reinicie o sistema usando o kernel do fornecedor com a correção.

Adquira o KernelCare hoje mesmo →

Detecção e análise de incidentes

Não existe um único indicador confiável do RefluXFS; portanto, considere cada um dos itens a seguir como uma pista, e não como uma prova.

A verificação mais precisa no disco aproveita o próprio ponto cego do bug: o conteúdo mudou, mas os metadados não. A verificação de pacotes calcula o hash do conteúdo do arquivo, por isso ela é acionada mesmo quando o mtime e o modo parecem estar corretos. Comece com a verificação de pacotes para pacotes sensíveis à segurança:

rpm -V shadow-utils sudo util-linux polkit

Um 5 na sequência de resultados da verificação indica uma incompatibilidade no resumo. Em um binário com setuid-root ou em um arquivo de configuração principal, sem carimbo de data/hora T correspondente ou alteração de modo M, isso é consistente com o tipo de modificação que o RefluXFS pode deixar. Em sistemas da família Debian, o comando `debsums -c` desempenha a mesma função. A verificação de pacotes não abrange todos os arquivos de configuração mutáveis importantes; portanto, complemente-a com backups confiáveis, registros de gerenciamento de configuração e hashes de arquivos comprovadamente válidos.

Concentre-se nos alvos de alto valor:

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

Em seguida, procure os sinais comportamentais: contas privilegiadas novas ou sem senha inesperadas, campos da conta root alterados, programas setuid cujo conteúdo não corresponde mais ao pacote instalado, chaves SSH inexplicáveis, ganhos de privilégios sem nenhum evento correspondente de sudo, login ou autenticação, picos de E/S direta simultânea provenientes de um processo sem privilégios e clonagem via reflink de arquivos protegidos em locais onde o usuário tem permissão de gravação.

Um carimbo de data/hora normal ou um modo de permissão inalterado não significa que o arquivo esteja limpo. Se um código não confiável foi executado em um host vulnerável durante o período de exposição, considere isso como uma possível violação de integridade e analise mais detalhadamente as contas, a configuração de autenticação e os serviços, em vez de interpretar um log do kernel sem alertas como prova de segurança.

Por que o RefluXFS é importante

É fácil subestimar o RefluXFS porque três detalhes parecem ser limitantes. Ele é local, não remoto. Requer o XFS. Requer reflinks.

No Linux corporativo, esses três elementos descrevem o ambiente padrão, e as máquinas que se enquadram nele são exatamente aquelas que executam o código de terceiros: locatários, pipelines de compilação, contêineres, plug-ins e serviços comprometidos.

A vulnerabilidade também ultrapassa a barreira de segurança de uma maneira incomum. Não há gravação direta no arquivo protegido, não é preciso contornar o SELinux e não há carga útil na memória do kernel. O kernel simplesmente grava dados válidos, controlados pelo invasor, no bloco de disco errado, e o resultado é persistente, com privilégios de root e discreto.

Há também uma lição sobre processos aqui, e é essa que você deve levar para sua fila de triagem. Para muitos administradores, o primeiro sinal que exigia ação pública pode ter sido uma atualização comum do kernel fornecida pelo fornecedor, lançada antes da divulgação do CVE e descrita como uma correção de corrupção de dados no XFS. Esse é o padrão silencioso de “correção primeiro, CVE depois”, e uma fila que se baseasse apenas em errata de segurança teria classificado uma LPE local com privilégios de root como manutenção de rotina. Fique atento aos avisos de correção de bugs do kernel, não apenas àqueles sinalizados como de segurança.

Para sistemas atualizados de forma convencional, instale a atualização do fornecedor e confirme se a máquina realmente inicializa com ela. Para frotas em que reinicializações de emergência representam um risco operacional, um patch sem reinicialização da KernelCare corrige a vulnerabilidade no sistema de arquivos XFS no kernel em execução, sem desligar os nós nem interromper as cargas de trabalho.

Adquira o KernelCare hoje mesmo →

Linha do tempo

Referências

• Qualys, “RefluXFS: Uma vulnerabilidade no kernel do Linux que permite a escalada de privilégios locais até o nível de root no sistema de arquivos XFS (CVE-2026-64600)”, 22 de julho de 2026: https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Aviso técnico da Qualys, “RefluXFS: Escalada de privilégios local por meio de uma condição de corrida de acesso direto de E/S com reflink no XFS”, oss-security 2026/q3, 22 de julho de 2026
• Medida provisória de mitigação do SystemTap pela Equipe de Segurança de Produtos da Red Hat, lista de discussão oss-security (tópico sobre o CVE-2026-64600)
• Página da Red Hat sobre o CVE, CVE-2026-64600: https://access.redhat.com/security/cve/cve-2026-64600
• Erratas de segurança da Red Hat RHSA-2026:39179 e RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• Correção no código-fonte, “xfs: reajustar o mapeamento do data fork após o ciclo do ILOCK” (commit 2f4acd0), incorporada em 16 de julho de 2026
• Commit 3c68d44a2b49, que introduziu um bug, “xfs: alocar blocos COW de E/S direta em iomap_begin” (Linux 4.11)
• The Hacker News, “Falha de nove anos no RefluXFS do Linux concede privilégios de root a usuários locais em instalações padrão do RHEL”: https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• Avisos de segurança aplicáveis às distribuições AlmaLinux, Rocky Linux, Oracle Linux, Fedora e Amazon Linux