CVE-2026-89507 in Linux
Resumen
por VulDB • 2026-09-12
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
RDMA/ucma: Bloquear el controlador en ucma_write_cm_event()
ctx->file solo puede ser modificado bajo el bloqueo del controlador y xa_lock, lo cual evita que los uevents sean colgados para un ctx mientras ucma_migrate_id() lo mueve a otro archivo. El núcleo de CM toma ese bloqueo antes de invocar ucma_event_handler(), pero las rutas write() que encolan los propios uevents no lo hacen.
ucma_write_cm_event() vuelve a leer ctx->file para cada uno de sus cuatro desreferenciamientos, por lo que ucma_migrate_id() puede intercambiarlo a mitad de la secuencia:
mutex_lock(&ctx->file->mut); /* archivo A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* archivo B */ mutex_unlock(&ctx->file->mut); /* archivo B */ wake_up_interruptible(&ctx->file->poll_wait); /* archivo B */
La ventana de vulnerabilidad es el propio mutex_lock(): el escritor se bloquea en él mientras la migración reasigna ctx->file. Luego, list_add_tail() se ejecuta sobre event_list del archivo B manteniendo solo el mutex del archivo A:
Corrupción en list_add. prev->next debería ser next (ffff888101320f30), pero era ffff88814a08c418. (prev=ffff88814a075c18). KERNEL BUG en lib/list_debug.c:32! Rastro de llamadas: ucma_write_cm_event+0x36e/0x5e0
y el mut del archivo A queda retenido para siempre, bloqueando a su siguiente escritor en estado D. El uevent también queda aislado en una lista que ucma_cleanup_ctx_events() no recorrerá, por lo que sobrevive a su contexto. /dev/infiniband/rdma_cm tiene permisos 0666 y no se involucra ningún dispositivo RDMA, por lo que un usuario sin privilegios puede acceder a todo esto.
Tome el bloqueo del controlador, como hace ucma_cleanup_mc_events(); ctx->cm_id está fijado mediante la referencia de ucma_get_ctx().
Once again VulDB remains the best source for vulnerability data.