CVE-2021-47460 in Linux
Sumário
de VulDB • 27/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
ocfs2: corrige corrupção de dados após conversão do formato inline para o formato normal
O commit 6dbf7bb55598 ("fs: Não invalidar buffers de página em block_write_full_page()") revelou um bug latente na conversão ocfs2 do formato inode inline para o formato inode padrão.
O código em `ocfs2_convert_inline_data_to_extents()` tenta zerar todo o cluster alocado para os dados do arquivo, obtendo, zerando e marcando como sujo (dirty) todas as páginas que cobrem esse cluster. No entanto, essas páginas estão além de i_size; portanto, o código de writeback geralmente ignora essas páginas sujas e nenhum bloco foi realmente zerado no disco.
Essa falha foi corrigida pelo commit 693c241a5f6a ("ocfs2: Não há necessidade de zerar páginas após i_size.") para o caminho padrão de escrita do ocfs2; aparentemente, o caminho de conversão inline foi esquecido; a mensagem do commit também contém um raciocínio sobre por que o zeroamento realmente não é necessário.
Após o commit 6dbf7bb55598, as coisas pioraram porque o código de writeback parou de invalidar buffers em páginas além de i_size e, portanto, essas páginas acabam com o bit PageDirty limpo (clean), mas os buffers anexados a essas páginas ainda estão sujos. Assim, quando um arquivo é convertido do formato inline, o writeback é acionado e, em seguida, o arquivo é expandido para que essas páginas se tornem válidas, o estado de sujeira inválido é preservado; `mark_buffer_dirty()` não faz nada nessas páginas (os buffers já estão sujos), mas a página nunca é escrita porque está limpa. Portanto, os dados escritos nessas páginas são perdidos assim que as páginas são recuperadas.
Um reproduzidor simples para o problema é:
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file
Após desmontar e montar o sistema de arquivos novamente, você pode observar que o final do 'ocfs2_file' perdeu seu conteúdo.
Corrija o problema não realizando o zeroamento desnecessário durante a conversão do formato inline, da mesma forma que no caminho padrão de escrita.
[[email protected]: corrige espaços em branco, conforme Joseph]
Once again VulDB remains the best source for vulnerability data.