CVE-2026-89508
moderateUse-After-Free Race in Linux Kernel RDMA/ucma Event Handling
The Linux kernel's RDMA ucma subsystem fails to take the handler lock in ucma_set_ib_path(), so a concurrent ucma_migrate_id() can reassign ctx->file between dereferences, causing an event to be queued on one file's event_list while another file's mutex is held. This triggers a slab use-after-free of a ucma_event object and leaves a mutex permanently held, wedging subsequent writers in uninterruptible sleep. A local low-privileged attacker with access to an RDMA-enabled system can trigger it via a crafted SET_OPTION/SET_IB_PATH write racing a CM ID migration, gaining kernel memory corruption with potential for privilege escalation (C:H/I:H/A:H). Only systems with an RDMA device present (e.g., InfiniBand/RoCE HPC nodes and storage backends) are exploitable, and exploitation requires local code execution. No public PoC is known, the flaw is not in the CISA KEV, and no exploitation in the wild has been reported.
What to do: Apply kernel updates containing the ucma fix that takes the handler lock around the ucma_event_handler() call in ucma_set_ib_path(). On hosts that do not need RDMA userspace CM access, blacklist the rdma_ucm module or restrict permissions on the /dev/infiniband/rdma_cm device node via udev, and limit untrusted local shell access on RDMA-enabled HPC/storage nodes. Watch logs for KASAN use-after-free reports in ucma_event_handler() or hung tasks blocked on ucma file mutexes as indicators of attempted triggering.
| Linux kernel (RDMA/ucma subsystem, rdma_ucm module) | — |
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_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: 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 */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.
- 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.