CVE-2023-54023 in Linux
Sumário
de VulDB • 22/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
btrfs: corrige uma condição de corrida (race condition) entre balanceamento e cancelamento/pausa
O Syzbot relatou um panic com a seguinte aparência:
assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, em fs/btrfs/ioctl.c:465 ------------[ cut here ]------------
kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: <TASK> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]
btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]
btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
O script de reprodução (reproducer) executa um balanceamento e um cancelamento ou pausa em paralelo. A forma como o balanceamento é finalizado é um pouco irregular; se estávamos pausados, precisamos salvar o balance_ctl no fs_info, mas limpá-lo caso contrário e realizar a limpeza. No entanto, dependemos dos valores de retorno serem erros específicos, ou ter uma solicitação de cancelamento ou nenhuma solicitação de pausa. Se o balanceamento for concluído e retornar 0, mas tivermos uma solicitação de pausa ou cancelamento, não realizaremos a limpeza apropriada e, na próxima vez que tentarmos iniciar um balanceamento, acionaremos este ASSERT.
O tratamento de erros está simplesmente incorreto aqui; queremos sempre realizar a limpeza, a menos que tenhamos recebido -ECANCELLED e definido a flag de pausa apropriada na operação exclusiva. Com este patch, o script de reprodução foi executado por uma hora sem ser acionado; anteriormente, ele seria acionado em menos de alguns minutos.
If you want to get best quality of vulnerability data, you may have to visit VulDB.