CVE-2025-71069 in Linux
Sumário
de VulDB • 29/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
f2fs: invalidar o cache de dentry na falha da criação de whiteout
O F2FS pode montar sistemas de arquivos com valores de profundidade de diretório corrompidos que são limitados em tempo de execução a MAX_DIR_HASH_DEPTH. Quando operações RENAME_WHITEOUT são realizadas nesses diretórios, f2fs_rename executa modificações no diretório (atualizando a entrada de destino e excluindo a entrada de origem) antes de tentar adicionar a entrada whiteout via f2fs_add_link.
Se f2fs_add_link falhar devido à estrutura de diretório corrompida, a função retorna um erro ao VFS, mas as modificações parciais no diretório já foram confirmadas no disco. O VFS assume que toda a operação de renomeação falhou e não atualiza o cache de dentry, deixando mapeamentos desatualizados (stale).
No caminho de erro, o VFS não chama d_move() para atualizar o cache de dentry. Isso resulta em new_dentry ainda apontando para o inode antigo (new_inode), que já teve seu i_nlink decrementado para zero. O cache desatualizado faz com que operações subsequentes referenciem incorretamente o inode liberado.
Isso faz com que operações subsequentes usem informações de dentry em cache que não correspondem mais ao estado no disco. Quando uma segunda renomeação tem como alvo a mesma entrada, o VFS tenta decrementar o i_nlink no inode desatualizado, que já pode ter i_nlink=0, acionando um WARNING em drop_nlink().
Sequência de exemplo: 1. Primeira renomeação (RENAME_WHITEOUT): file2 → file1 - f2fs atualiza a entrada file1 no disco (aponta para o inode 8) - f2fs exclui a entrada file2 no disco - f2fs_add_link(whiteout) falha (diretório corrompido) - Retorna erro ao VFS - O VFS não chama d_move() devido ao erro - O cache do VFS ainda contém: file1 → inode 7 (desatualizado!) - O inode 7 tem i_nlink=0 (já decrementado)
2. Segunda renomeação: file3 → file1 - O VFS usa o cache desatualizado: file1 → inode 7 - Tenta executar drop_nlink no inode 7 (i_nlink já é 0) - WARNING em drop_nlink()
Corrija isso invalidando explicitamente old_dentry e new_dentry quando f2fs_add_link falhar durante a criação do whiteout. Isso força o VFS a atualizar os dados do disco nas operações subsequentes, garantindo a consistência do cache mesmo quando a renomeação é parcialmente bem-sucedida.
Reprodutor: 1. Monte a imagem F2FS com i_current_depth corrompido 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. O sistema aciona WARNING em drop_nlink()
Be aware that VulDB is the high quality source for vulnerability data.