CVE-2026-89508

What it actually does

A local race in the Linux kernel RDMA userspace connection manager (ucma) lets ucma_set_ib_path() invoke ucma_event_handler() from the write path without the handler lock that keeps ctx->file stable. A concurrent ucma_migrate_id() can reassign ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so list_add_tail() inserts a uevent onto a different file's event_list under the wrong mutex. That produces a slab use-after-free on a ucma_event, kernel heap corruption, and a mutex left held that can wedge later writers in uninterruptible sleep. Confidentiality, integrity, and availability of the kernel are all at risk (local DoS, hang, or potential privilege escalation). A bound, address-resolved cm_id and a present RDMA device are required.

Why it matters to the business

Linux hosts that expose RDMA (InfiniBand, RoCE, iWARP) to non-admin users—typical in HPC, AI/ML clusters, high-performance storage, and some cloud tenancy models—can be crashed, hung, or potentially fully compromised by a logged-in user. Impact is host-wide: D-state hangs on RDMA writers, kernel panics, and possible loss of isolation on shared fabrics. The CVE is not in CISA KEV, is not associated with ransomware, has exploit maturity None, and a very low, flat EPSS (~0.13% over 30 days), so opportunistic mass exploitation is unlikely; still, CVSS 7.8 High and 32 days since publication justify prompt kernel updates on any RDMA-enabled fleet. Systems without RDMA hardware or with ucma unused are not practically exposed.

How an attack unfolds

An attacker who already has a local account on a Linux system with an RDMA device present opens the userspace RDMA connection-manager interface and obtains a bound, address-resolved communication ID. They then race a SET_OPTION write that sets an IB path against a concurrent CM ID migration. Because the event handler previously ran without the handler lock and re-reads ctx->file between taking a mutex and inserting onto the event list, the uevent can be queued on another file's list. A second thread can dequeue and free that object, producing a kernel use-after-free in list-add validation. The resulting heap corruption can panic or hang the kernel; in principle it may be turned into local privilege escalation. No named APT groups or campaigns are reported against this CVE, and there is no public exploit maturity.

How to fix it

Apply Linux kernel updates from your distribution or vendor that include the RDMA/ucma fix taking the handler lock around ucma_event_handler() in ucma_set_ib_path(). No per-package fixed versions were supplied with this record, so use distro security advisories and kernel changelogs that mention CVE-2026-89508 or the ucma handler-lock change. Until patched, restrict access to RDMA userspace CM device nodes (commonly under /dev/infiniband/, including rdma_cm) to trusted groups, and unload or blacklist rdma_ucm where RDMA userspace CM is not required. Reboot into the patched kernel; this is not a userspace-only fix.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the handler lock around the ucma_event_handler() call in ucma_set_ib_path() (RDMA/ucma). Verify uname -r and distro package versions against the advisory that claims the fix. After patching, confirm rdma_ucm (if loaded) is from the new kernel, that device node permissions on RDMA CM nodes match policy, and that unprivileged accounts cannot open those nodes where RDMA is not needed. Do not attempt to reproduce the race in production; treat KASAN/list-corruption oopses involving these symbols as evidence of prior exposure instead.

Typical attack path

1. Obtain local unprivileged access on a Linux host that has an RDMA device
2. Open the RDMA userspace connection manager and establish a bound, address-resolved CM ID
3. Race an IB path SET_OPTION write against concurrent CM ID migration so the event handler runs without a stable file pointer
4. Trigger a use-after-free on the ucma event list and corrupt kernel heap state
5. Cause a kernel hang or panic, or attempt to convert the memory corruption into local privilege escalation

How to detect it

This is a local kernel race with no network C2 pattern; look for evidence of attempted or successful triggering in kernel and audit logs rather than IDS signatures. Search dmesg, journalctl -k, crash dumps, and kdump/vmcore for KASAN or list-corruption reports citing ucma_event_handler, ucma_set_ib_path, ucma_set_option, ucma_write, ucma_get_event, or __list_add_valid_or_report, and for hung_task / D-state reports on processes blocked in ucma write paths. Audit open/use of RDMA CM device nodes and unexpected rdma_ucm activity by unprivileged UIDs. Post-crash slab traces that show a ucma_event allocated via ucma_write_cm_event and freed via ucma_get_event are consistent with this bug. No public exploit tooling or named actor TTPs are documented.

• BUG: KASAN: slab-use-after-free in __list_add_valid_or_report
• ucma_event_handler
• ucma_set_ib_path
• ucma_set_option
• ucma_write
• ucma_get_event
• ucma_write_cm_event
• ucma_migrate_id
• /dev/infiniband/rdma_cm
• rdma_ucm

What your security team should do

• Prioritize kernel updates on RDMA-enabled hosts (HPC, GPU/storage fabrics, cloud instances with InfiniBand/RoCE) even though KEV is false and EPSS is low
• Inventory systems with RDMA devices or rdma_ucm loaded and restrict /dev/infiniband/* (especially rdma_cm) to trusted users until patched
• Blacklist or unload rdma_ucm on hosts that do not need userspace RDMA connection management
• Watch kernel logs for ucma/KASAN list UAF and hung-task reports as a stopgap detection control
• Track distro advisories for the exact kernel package that includes the ucma handler-lock fix; reboot after install