CVE-2026-89507
massLinux kernel RDMA/ucma race lets unprivileged local users corrupt kernel memory
The Linux kernel's RDMA userspace Connection Manager ABI (ucma) fails to take the handler lock inside ucma_write_cm_event(), so while a writer sleeps in mutex_lock() on one file's mutex, ucma_migrate_id() can reassign ctx->file, and the subsequent list_add_tail() runs against the new file's event list while holding only the old file's mutex. An unprivileged local user can trigger this by racing write() calls on /dev/infiniband/rdma_cm (which is mode 0666) against CM ID migration, with no RDMA hardware required. The result is kernel linked-list corruption (BUG in lib/list_debug.c, with potential for memory corruption given the C:H/I:H/A:H CVSS impact), a mutex left locked forever that wedges subsequent writers in uninterruptible D state, and an event leaked outside its context — effectively a local privilege-escalation or denial-of-service primitive on any host with the ucma interface available to local users, including containers sharing the host kernel. The flaw is fixed upstream by taking the handler lock as other ucma paths already do; no public proof of concept exists and there is no evidence of exploitation in the wild.
What to do: Apply a kernel build containing the ucma_write_cm_event() handler-lock fix as soon as your distro ships it. Until then, mitigate by restricting /dev/infiniband/rdma_cm to root (chmod 600 or a udev rule) or blacklisting the ucma module on hosts that do not use RDMA. Monitor for lib/list_debug.c BUG splats referencing ucma_write_cm_event and for processes stuck in D state holding a ucma file mutex, which are indicators of the race being hit.
| Linux kernel (RDMA/ucma subsystem) | Affected versions not enumerated in the source data; fixed by the upstream commit that takes the handler lock in ucma_write_cm_event(). Any kernel exposing /dev |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_write_cm_event() ctx->file may only be changed under the handler lock and the xa_lock, which is what stops uevents being queued for a ctx while ucma_migrate_id() moves it to another file. The CM core takes that lock before invoking ucma_event_handler(), but the write() paths that queue uevents themselves do not. ucma_write_cm_event() re-reads ctx->file for each of its four dereferences, so ucma_migrate_id() can swap it mid-sequence: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ The window is the mutex_lock() itself: the writer sleeps in it while the migration reassigns ctx->file. The list_add_tail() then runs on file B's event_list holding only file A's mutex: list_add corruption. prev->next should be next (ffff888101320f30), but was ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG at lib/list_debug.c:32! Call Trace: ucma_write_cm_event+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 ucma_cleanup_ctx_events() will not walk, so it outlives its context. /dev/infiniband/rdma_cm is 0666 and no RDMA device is involved, so an unprivileged user reaches all of this. Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is pinned by the ucma_get_ctx() reference.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.