EUVD-2026-93181
GHSA-6rqw-4vwj-ww2r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local access to RDMA cm device
-
ExploitRace two concurrent JOIN_MCAST on same address
-
ExecutionTrigger use-after-free of freed ucma_multicast
-
ImpactCorrupt kernel memory for escalation or crash
Vulnerability Assessment
| Exploitation Conditions | Requires the RDMA user-space connection-manager (ucma) interface to be present and accessible - i.e. the kernel built with CONFIG_INFINIBAND_USER_ACCESS/RDMA_CM and a reachable /dev/infiniband/rdma_cm device - plus an RDMA transport (RoCE) in use, since the flaw is in rdma_join_multicast's RoCE work path. The attacker must have LOCAL access with privileges sufficient to open the RDMA cm device (PR:L) and must issue two concurrent JOIN_MCAST calls for the same multicast address AND force a copy_to_user failure to win the race. Limiting factors: no remote vector, no exploitation against systems lacking RDMA/RoCE, a required timing window between the second insert and the leave (reducing reliability), and no user interaction needed once local access is obtained. |
| Impact | Signals point consistently to a LOW real-world priority despite the 7.8 'High' CVSS base score. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) requires LOCAL access and at least low-level privileges - there is no network-exploitable path - so the high score comes entirely from full C/I/A impact typical of a kernel use-after-free, not from easy reachability. EPSS reinforces this: 0.18% probability at the 7th percentile indicates exploitation is considered very unlikely in the near term. The CVE is NOT on CISA KEV and no public exploit code is referenced in the provided data, so exploitation status is 'no public exploit identified at time of analysis'. No SSVC decision record is provided. One tension worth flagging: the CVSS vector lists AC:L, but the root cause is a race condition between two concurrent JOIN_MCAST calls (a time-sensitive double-insert/use-after-free), which in practice raises attack complexity - a reliable exploit must win a timing window, so AC:L likely understates difficulty. Overall this is a legitimate kernel memory-safety fix, but as a local, privilege- and configuration-gated race it is a routine patch-management item rather than an emergency, and only relevant to systems that actually use RDMA/RoCE. |
| Exploit ScenarioDerived | A local user with access to the RDMA connection-manager interface issues two concurrent rdma_join_multicast (JOIN_MCAST) calls for the same multicast address, racing a copy_to_user failure so that a second CMA multicast entry is inserted before the first thread's leave. The subsequent leave-by-address cancels the newer work while the older RoCE worker dereferences the ucma_multicast the first thread already freed, yielding a use-after-free in kernel memory. No public proof-of-concept is referenced, and winning the timing window makes reliable exploitation non-trivial. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
A race-condition use-after-free in the Linux kernel's RDMA user-space connection manager (ucma) allows a local user who can open /dev/infiniband/rdma_cm to corrupt kernel memory and potentially escalate privileges. Two concurrent JOIN_MCAST calls for the same multicast address, combined with a forced copy_to_user() failure, can leave a queued RoCE work item dereferencing a ucma_multicast structure that another thread has already freed, because ucma_process_join() dropped ctx->mutex after a successful join and reacquired it only on error. No public exploit code or confirmed active exploitation has been identified at time of analysis (CISA KEV: not listed), EPSS is a low 0.18% (7th percentile), and real-world risk is limited by the requirement for local RDMA/RoCE configuration plus a narrow timing window - so despite the 7.8 base score this is a LOW-priority issue in practice.
RemediationAI
Vendor-released patch: apply the upstream stable fixes - kernels 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8, or 7.3-rc4 (or later), each carrying the corresponding git.kernel.org/stable commit listed in the references, and take the same or newer kernel from your distribution vendor. If immediate kernel upgrade is not possible, the effective compensating control is to remove the attack surface: either build/run the kernel without CONFIG_INFINIBAND_USER_ACCESS (which disables ucma and breaks all RDMA user-space verbs consumers, not just multicast), or restrict access to /dev/infiniband/rdma_cm to a tightly scoped group/SELinux label so that only trusted RDMA applications can issue JOIN_MCAST (this does not fix the bug, it only denies PR:L attackers the required device access and must be combined with RBAC auditing). Because the flaw requires concurrent multicast joins plus a copy_to_user failure, avoiding application-level multicast join patterns on untrusted hosts and monitoring for repeated ucma join/leave churn reduces the window, but neither is a substitute for the patch. Distro advisories should be tracked through the NVD/EUVD entry for CVE-2026-98253 (EUVD-2026-93181) to confirm the fixed kernel build for each supported release.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the RDMA CM user-space ABI, requiring a kernel built with CONFIG_INFINIBAND_USER_ACCESS/RDMA_CM and an accessible /dev/infiniband/rdma_cm character device, and it only manifests on RDMA transports that use multicast join work queues such as RoCE. rdma_join_multicast() queues work that later reads the ucma_multicast object via event->param.ud.private_data and list_add()s the new CMA multicast entry at the head of id_priv->mc_list, while rdma_leave_multicast() matches entries only by sockaddr and destroys the first match. In ucma_process_join(), ctx->mutex was released after a successful join and retaken only when copy_to_user() returned an error; this opened a window in which a second concurrent JOIN_MCAST for the same address could insert a newer entry after the first thread's copy_to_user failure and before its leave. The subsequent leave then cancelled the newer work while the older worker still referenced the ucma_multicast that the first thread freed - a classic concurrency-induced use-after-free (no CWE was assigned in the CNA data, but the root-cause class is an unsynchronized check-and-act race, CWE-362, with use-after-free impact, CWE-416). The fix holds ctx->mutex from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast(), and explicitly avoids leaving when the join itself failed so that an earlier successful join of the same address is not destroyed. Public CPE data only carries the broad cpe:2.3:a:linux:linux entries, so precise affectedness must be determined from distribution kernel versions and the upstream stable patches.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local-only via the RDMA cm device (AV:L, PR:L); winning the concurrent JOIN race and forcing copy_to_user failure raises complexity (AC:H); kernel UAF gives full C/I/A.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ucma: Serialize join and leave on copy_to_user failure
rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit.
ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees.
Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join.
Executive ViewAI
Organizations running Linux systems with RDMA/RoCE enabled are affected by a race-condition use-after-free in the kernel's RDMA user-space connection manager (ucma), which could allow a local user to escalate privileges. The vulnerability has a high base CVSS score of 7.8, but the practical risk is low because exploitation requires local access, specific RDMA configuration, and a narrow timing window, and no public exploit identified at time of analysis. Patch available per vendor advisory; leadership should prioritize patching based on standard risk management, not as an emergency.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB