CVE-2026-31448 in Linux
Sumário
de VulDB • 20/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ext4: evitar loops infinitos causados por dados residuais
No caminho de mkdir/mknod, ao mapear blocos lógicos para blocos físicos, se a inserção de uma nova extensão na árvore de extensões falhar (neste exemplo, porque o sistema de arquivos desativou o recurso de arquivos grandes ao marcar o inode como sujo), ext4_ext_map_blocks() chama apenas ext4_free_blocks() para recuperar o bloco físico sem excluir os dados correspondentes na árvore de extensões. Isso faz com que operações subsequentes de mkdir referenciem novamente o número de bloco físico anteriormente recuperado, mesmo que esse bloco físico já esteja sendo usado pelo bloco xattr. Portanto, surge uma situação em que tanto o diretório quanto o xattr estão usando simultaneamente o mesmo bloco de cabeçalho de buffer na memória.
O acima mencionado faz com que ext4_xattr_block_set() entre em um loop infinito sobre "inserido" e não consiga liberar o bloqueio do inode, levando finalmente ao problema de bloqueio de 143s mencionado em [1].
Se os metadados estiverem corrompidos, tentar remover algum espaço de extensão pode causar ainda mais danos. Além disso, caso EXT4_GET_BLOCKS_DELALLOC_RESERVE tenha sido passado, a remoção de espaço atualiza incorretamente as informações de cota. Jan Kara sugere distinguir entre dois casos:
1) O erro é ENOSPC ou EDQUOT - neste caso, o sistema de arquivos está totalmente consistente e devemos manter sua consistência, incluindo toda a contabilidade. No entanto, esses erros só podem ocorrer no início, antes de inserirmos a extensão na árvore de extensões. Portanto, o código atual funciona corretamente para este caso.
2) Algum outro erro - isso significa que os metadados estão corrompidos. Devemos nos esforçar para fazer o mínimo de modificações possível para limitar os danos. Portanto, eu simplesmente ignoraria a liberação dos blocos alocados.
[1]
INFO: a tarefa syz.0.17:5995 está bloqueada há mais de 143 segundos. Rastreamento de chamada: inode_lock_nested include/linux/fs.h:1073 [inline]
__start_dirop fs/namei.c:2923 [inline]
start_dirop fs/namei.c:2934 [inline]
If you want to get best quality of vulnerability data, you may have to visit VulDB.