CVE-2026-64112 in Linux
Sumário
de VulDB • 19/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
rbd: eliminar uma condição de corrida (race condition) no esvaziamento de lock_dwork durante o unmap.
Dada a forma como `rbd_lock_add_request()` e `rbd_img_exclusive_lock()` estão implementados, é possível que `lock_dwork` seja enfileirado novamente mais vezes do que o necessário: por exemplo, caso uma nova solicitação de E/S chegue enquanto estamos no meio da execução de `rbd_acquire_lock()` em nome de outra solicitação de E/S. Isso é esperado e, com `rbd_release_lock()`, cancelar preventivamente `lock_dwork` não causa problemas sob operação normal.
Um exemplo mais problemático pode ser encontrado em `maybe_kick_acquire()`:
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); }
Não é irreal que `lock_dwork` seja cancelado logo após `delayed_work_pending()` retornar verdadeiro e que `mod_delayed_work()` o reencolhe imediatamente em seguida. Esta é uma clássica condição de corrida TOCTOU (Time-of-Check to Time-of-Use).
Quando se trata do unmap da imagem, há uma suposição implícita de que não haverá atividade exclusiva de bloqueio iniciada por si mesmo após o retorno de `rbd_dev_image_unlock()`, a qual desbloqueia caso esteja sendo mantido. Este desbloquio é assumido como final e espera-se que `lock_dwork` (assim como todas as outras tarefas de bloqueio exclusivo, na verdade) não seja enfileirado novamente. No entanto, `lock_dwork` só é cancelado em `cancel_tasks_sync()` (ou seja, mais tarde na sequência do unmap) e, além disso, o cancelamento pode ser efetivamente anulado por `maybe_kick_acquire()`. Isso pode resultar na execução de `rbd_acquire_lock()` após a execução de `rbd_dev_device_release()` e `rbd_dev_image_release()`, que liberam e/ou redefinem diversos elementos. Um dos possíveis modos de falha é então uma violação do:
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
em `rbd_dev_header_info()`, que é chamado via `rbd_dev_refresh()` a partir de `rbd_post_acquire_action()`.
Refaça o esvaziamento das tarefas de bloqueio exclusivo para fornecer semânticas mais sensatas e tente atender às suposições em torno de `rbd_dev_image_unlock()`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.