CVE-2026-98253: RDMA/ucma: Serialize join and leave on copy_to_user failure
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ucma: Serialize join and leave on copytouser failure
rdmajoinmulticast() queues RoCE work that later reads the ucmamulticast through event->param.ud.privatedata, then listadd()s the CMA multicast at the head of idpriv->mclist. rdmaleavemulticast() matches only by sockaddr and destroys the first hit.
ucmaprocessjoin() used to drop ctx->mutex after a successful join and retake it only if copytouser() failed. Two concurrent JOINMCAST 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 ucmamulticast that the first thread frees.
Keep ctx->mutex held from rdmajoinmulticast() through copytouser() and, on -EFAULT, through rdmaleavemulticast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mclist, and a leave-by-addr would destroy an earlier successful join.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Keep ctx->mutex held from rdma_join_multicast() through copy_to_user(), and serialize JOIN_MCAST and leave operations so that a leave cannot cancel or destroy an in-progress join when copy_to_user() fails.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Exploitation requires local access and low privileges, according to the CVSS vector. The vulnerable path is in the Linux kernel RDMA/ucma multicast join and leave handling.
What conditions are needed to trigger the race?
Two concurrent JOIN_MCAST operations using the same address must allow a second CMA multicast entry to be inserted before the first operation performs its leave. The problematic cleanup path is reached when copy_to_user() fails after a successful join.
What is the impact of a successful trigger?
The leave operation can cancel the newer multicast work while an older worker still references ucma_multicast data freed by the first thread. This creates a use-after-free condition with high confidentiality, integrity, and availability impact in the CVSS assessment.
What does the fix change?
The fix holds ctx->mutex from rdma_join_multicast() through copy_to_user(), and through rdma_leave_multicast() when copy_to_user() returns -EFAULT. It also avoids issuing a leave when the join itself failed, because that could remove an earlier successful join for the same address.