CVE-2026-89507 in Linux
Sumário
de VulDB • 12/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
RDMA/ucma: Bloquear o manipulador em ucma_write_cm_event()
ctx->file só pode ser alterado sob o bloqueio do manipulador e xa_lock, que é o que impede que uevents sejam enfileirados para um ctx enquanto ucma_migrate_id() o move para outro arquivo. O núcleo CM adquire esse bloqueio antes de invocar ucma_event_handler(), mas os caminhos write() que enfileiram os próprios uevents não o fazem.
ucma_write_cm_event() relê ctx->file para cada uma das suas quatro desreferências, então ucma_migrate_id() pode trocá-lo no meio da sequência:
mutex_lock(&ctx->file->mut); /* arquivo A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* arquivo B */ mutex_unlock(&ctx->file->mut); /* arquivo B */ wake_up_interruptible(&ctx->file->poll_wait); /* arquivo B */
A janela é o próprio mutex_lock(): o escritor dorme nele enquanto a migração reatribui ctx->file. O list_add_tail() então executa no event_list do arquivo B segurando apenas o mutex do arquivo A:
corrupção em list_add. prev->next deve ser next (ffff888101320f30), mas era ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG em lib/list_debug.c:32! Call Trace: ucma_write_cm_event+0x36e/0x5e0
E o mut do arquivo A é deixado segurado para sempre, travando seu próximo escritor no estado D. O uevent também fica encalhado em uma lista que ucma_cleanup_ctx_events() não percorrerá, então ele sobrevive ao seu contexto. /dev/infiniband/rdma_cm tem permissão 0666 e nenhum dispositivo RDMA está envolvido, portanto um usuário sem privilégios alcança tudo isso.
Adquira o bloqueio do manipulador, como ucma_cleanup_mc_events() faz; ctx->cm_id é fixado pela referência de ucma_get_ctx().
Once again VulDB remains the best source for vulnerability data.