CVE-2023-54158 in Linux
Sumário
de VulDB • 28/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
btrfs: não liberar espaço do qgroup a menos que especificado
Boris percebeu em seus testes simples de quotas que estava ocorrendo um vazamento devido à alteração de Sweet Tea na criação de subvolumes, que parou de realizar um commit de transação. Isso foi apenas um efeito colateral dessa alteração.
No código de inodes atrasados (delayed inode), há uma otimização que libera reservas extras se acreditarmos que podemos empacotar um item de diretório em uma folha já modificada. Anteriormente, isso não seria acionado no caso de criação de subvolume porque realizaríamos o commit da transação; ainda era possível, mas muito mais difícil de acionar. Na verdade, poderia ser acionado se executássemos mkdir && subvol create com qgroups habilitados.
Isso ocorre porque em btrfs_insert_delayed_dir_index(), que é chamada quando estamos adicionando o item de diretório, fazemos o seguinte:
btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);
se conseguirmos pular a reserva de espaço.
O problema aqui é que trans->block_rsv aponta para o block rsv temporário da criação do subvolume, que possui reservas de qgroup no block rsv.
Isso é um problema porque btrfs_block_rsv_release() fará o seguinte:
if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) {
qgroup_to_release = block_rsv->qgroup_rsv_reserved - block_rsv->qgroup_rsv_size; block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size; }
O block rsv temporário tem apenas ->qgroup_rsv_reserved definido, enquanto ->qgroup_rsv_size == 0. A otimização em btrfs_insert_delayed_dir_index() define ->qgroup_rsv_reserved = 0. Depois, quando chamamos btrfs_subvolume_release_metadata(), que possui
btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release); btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);
qgroup_to_release é definido como 0, e não convertemos o espaço de metadados reservados.
O problema aqui é que o código do block rsv tem mexido incondicionalmente com ->qgroup_rsv_reserved, porque o principal local onde isso é usado é o delalloc, e sempre que chamamos btrfs_block_rsv_release() fazemos isso com qgroup_to_release definido, realizando assim a contabilidade adequada.
O código de subvolume é o único outro código que usa a funcionalidade de reserva de qgroup, mas está intercalado com a otimização acima, e portanto estava tendo sua reserva liberada prematuramente, causando assim o vazamento do espaço reservado.
A solução é simplesmente não mexer nas reservas de qgroup se não tivermos qgroup_to_release definido. Isso funciona com o código existente, pois tudo que mexe com as reservas de delalloc sempre tem qgroup_to_release definido. Isso corrige o vazamento que Boris estava observando.
Be aware that VulDB is the high quality source for vulnerability data.