CVE-2026-89507

What it actually does

A local race in the Linux kernel RDMA userspace CM (ucma) path allows concurrent ucma_write_cm_event() and ucma_migrate_id() to swap ctx->file between mutex_lock, list_add_tail, mutex_unlock, and wake_up. The result is kernel list corruption (BUG in list_debug), a mutex left permanently held so subsequent writers sleep forever in D state, and a uevent stranded on a list that cleanup will not walk—so the event outlives its context. Because /dev/infiniband/rdma_cm is typically mode 0666 and no RDMA hardware is required, an unprivileged local process can reach the race. Memory corruption and a use-after-free of the event/context pair imply kernel crash, denial of service, and a plausible path to local privilege escalation (CVSS C:H/I:H/A:H).

Why it matters to the business

Any multi-user Linux host that exposes the InfiniBand/RDMA CM device—HPC nodes, storage/fabric gateways, cloud or lab systems with rdma-core, even if no RDMA NIC is present—can be crashed or potentially fully compromised by a logged-in unprivileged user. Impact is availability (kernel panic or wedged writers), integrity, and confidentiality of the host. The issue has been public for about 32 days, is not in CISA KEV, shows no known in-the-wild exploitation or ransomware use, and has a low, flat EPSS (~0.0017). Residual risk is still material on shared, multi-tenant, or developer machines because exploitation requires only local access and no special hardware. Downstream kernel consumers inherit the defect until the ucma handler-lock fix is applied.

How an attack unfolds

An unprivileged local attacker opens /dev/infiniband/rdma_cm and creates a CM context, then concurrently issues a write that queues a CM event (ucma_write_cm_event) while another thread or process migrates that ID to a different file (ucma_migrate_id). The write path re-reads ctx->file without the handler lock, so migration can change the file while the writer is blocked in mutex_lock. The subsequent list_add_tail and unlock then operate on mismatched files, corrupting kernel lists, leaving a mutex held, and parking a uevent on the wrong list. The attacker repeats the race until a BUG, hang, or corrupted kernel object is obtained; with sufficient control of allocation timing this class of list/UAF primitive can be turned toward privilege escalation. No named threat actors or public exploit maturity are associated with this CVE.

How to fix it

Apply the vendor/distro kernel update that takes the handler lock in ucma_write_cm_event() (same locking as ucma_cleanup_mc_events(), with ctx->cm_id pinned by ucma_get_ctx()). Rebuild or install the patched kernel and reboot into it. If a patch is not yet available, restrict access to /dev/infiniband/rdma_cm (tighten udev/permissions from 0666, use groups or hide the node) so unprivileged users cannot open it; unload or blacklist rdma_ucm / related RDMA userspace CM modules on hosts that do not need RDMA CM. There is no application-level workaround inside the race window. Confirm the changelog or commit explicitly mentions locking the handler in ucma_write_cm_event.

How to confirm the fix worked

Verify the running kernel includes the ucma handler-lock fix (uname -r vs. distro advisory; grep the changelog or source for the lock in ucma_write_cm_event). Confirm /dev/infiniband/rdma_cm either is absent, is not world-accessible, or is only reachable by intended groups. After patching and reboot, regression-test RDMA CM migrate-id plus event write under concurrency and ensure no list_debug BUG, D-state writers, or leaked uevents. On unpatched hosts, treat world-writable rdma_cm plus an unpatched kernel as exposed.

Typical attack path

1. Obtain local unprivileged code execution or a login on a Linux host that exposes /dev/infiniband/rdma_cm.
2. Open the RDMA CM device and allocate a userspace CM context/id.
3. Race a write that queues a CM event against a migrate-id operation on the same context so ctx->file changes mid-sequence.
4. Trigger kernel list corruption, a stuck mutex, and/or a stranded uevent (crash, hang, or UAF).
5. Optionally convert the resulting kernel memory corruption into elevated privileges or persistent denial of service.

How to detect it

This is a local kernel race; there is no network C2. Look for prior exploitation or crash attempts in kernel logs, crash dumps, and process state rather than packet captures. Search dmesg, journald/kern.log, kdump/vmcore, and panic traces for list_add corruption at lib/list_debug.c with ucma_write_cm_event on the stack, and for tasks stuck in D state in ucma write/lock paths. Correlate with opens of /dev/infiniband/rdma_cm, rdma_ucm module use, and unprivileged processes issuing RDMA CM ioctls/writes around the same time. Stranded uevents or use-after-free reports in RDMA/ucma cleanup are additional artifacts. Absence of these logs does not prove non-exploitation if the host was rebooted without persistent kernel logging.

• kernel BUG at lib/list_debug.c
• list_add corruption
• ucma_write_cm_event
• ucma_migrate_id
• RDMA/ucma
• /dev/infiniband/rdma_cm
• rdma_ucm

What your security team should do

• Prioritize kernel updates on multi-user, HPC, cloud, and any host where unprivileged users can open /dev/infiniband/rdma_cm; reboot into the patched kernel.
• Until patched, restrict or remove /dev/infiniband/rdma_cm (permissions, udev, module blacklist) so only trusted users can reach RDMA CM.
• Hunt historical kernel logs for list_add corruption and ucma_write_cm_event BUG traces; treat hits as likely exploitation or crash attempts.
• Inventory systems with RDMA/InfiniBand userspace CM loaded even if no RDMA NIC is present.
• Track distro advisories until exact fixed kernel versions for each platform are confirmed; this CVE is not KEV and EPSS is low, but CVSS 7.8 local High still warrants timely patching on shared hosts.