CVE-2026-89507: RDMA/ucma: Lock the handler in ucma_write_cm_event()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ucma: Lock the handler in ucmawritecmevent()
ctx->file may only be changed under the handler lock and the xalock, which is what stops uevents being queued for a ctx while ucmamigrateid() moves it to another file. The CM core takes that lock before invoking ucmaeventhandler(), but the write() paths that queue uevents themselves do not.
ucmawritecmevent() re-reads ctx->file for each of its four dereferences, so ucmamigrateid() can swap it mid-sequence:
mutexlock(&ctx->file->mut); / file A / listaddtail(&uevent->list, &ctx->file->eventlist); / file B / mutexunlock(&ctx->file->mut); / file B / wakeupinterruptible(&ctx->file->pollwait); / file B /
The window is the mutexlock() itself: the writer sleeps in it while the migration reassigns ctx->file. The listaddtail() then runs on file B's eventlist holding only file A's mutex:
listadd corruption. prev->next should be next (ffff888101320f30), but was ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG at lib/listdebug.c:32! Call Trace: ucmawritecmevent+0x36e/0x5e0
and file A's mut is left held forever, wedging its next writer in D state. The uevent is also stranded on a list ucmacleanupctxevents() will not walk, so it outlives its context. /dev/infiniband/rdmacm is 0666 and no RDMA device is involved, so an unprivileged user reaches all of this.
Take the handler lock, as ucmacleanupmcevents() does; ctx->cmid is pinned by the ucmagetctx() reference.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel's RDMA UCMA functionality are exposed when a connection-management context can be migrated between files while user events are being queued for that context.
What conditions trigger the failure?
The race requires ucma_migrate_id() to change ctx->file while ucma_write_cm_event() is waiting to acquire the old file's mutex. The event may then be added to the new file's event list while only the old file's mutex is held.
How can I tell whether this has already occurred?
Affected systems may report a kernel BUG in lib/list_debug.c related to list corruption, with ucma_write_cm_event in the call trace. The old file's mutex can also remain locked, causing its next writer to block indefinitely.
What can be done if an update cannot be applied immediately?
Avoid concurrent UCMA context migration and event-queueing activity where possible. The described race specifically depends on ucma_migrate_id() changing the context's associated file during event delivery.