CVE-2026-89507

RDMA/ucma: Lock the handler in ucma_write_cm_event()

Published Sep 11, 2026 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Description
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.

Analysis

AI-generated

Technical impact

A race condition exists in the Linux kernel RDMA UCMA subsystem where ucma_write_cm_event() reads ctx->file multiple times without holding the handler lock while a concurrent ucma_migrate_id() may change it between reads. This can lead to corruption of the kernel linked‑list that queues uevents, causing a kernel BUG, leaving a mutex locked forever and hanging subsequent writers. The outcome is a local denial of service that can force the system to become unavailable or crash.

Affected Systems

All Linux kernels that include the UCMA CM code and expose the /dev/infiniband/rdma_cm character device with mode 0666 are affected until the upstream fix is applied. No specific release versions are listed, so any kernel that contains the UCMA core and the RDMA CM device is vulnerable.

Risk and Exploitability

The CVSS score of 7.8 indicates high severity. The EPSS score is below 1%, and the vulnerability is not listed in the CISA KEV catalog, indicating no widespread exploitation is currently documented. The likely attack vector is local, requiring an unprivileged user to interact with /dev/infiniband/rdma_cm and trigger the race that leads to list corruption and a deadlock.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the upstream kernel patch that locks ctx->file in ucma_write_cm_event() to eliminate the race condition.
  • If a kernel update cannot be applied immediately, restrict access to /dev/infiniband/rdma_cm by changing its permissions or using a device deny list, limiting the ability of non‑kernel users to trigger the vulnerability.
  • Continuously monitor kernel logs for 'kernel BUG' entries related to lib/list_debug.c and investigate any uevent list corruption events.

Generated by OpenCVE AI on September 15, 2026 at 22:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
History
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Important

Type Values Removed Values Added
Description 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.
Title RDMA/ucma: Lock the handler in ucma_write_cm_event()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 19, 2026, 8:47 AM
Reserved
Sep 11, 2026, 7:38 PM
Status
Received
Published
Sep 11, 2026, 8:19 PM
Modified
Oct 19, 2026, 9:17 AM
Severity
Important
Public date
Sep 11, 2026, 7:43 PM