CVE-2026-98253 in Linuxinfo

Summary

by MITRE • 10/06/2026

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.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/06/2026

The vulnerability identified in the Linux kernel's RDMA user-space connection manager (ucma) subsystem represents a classic race condition rooted in improper synchronization of shared data structures during error handling paths. The core issue lies within the interaction between rdma_join_multicast and rdma_leave_multicast functions, which manage multicast group memberships for Remote Direct Memory Access operations. Specifically, when joining a multicast group, the system queues RoCE work that eventually accesses ucma_multicast structures via event parameters and adds the CMA multicast entry to a private list associated with the connection manager identifier. Conversely, leaving a multicast group involves searching for an existing entry based on socket address information and destroying the first match found in that list. The fundamental flaw arises from how context mutexes are managed during these operations when user-space memory copying fails.

Historically, ucma_process_join would release the context mutex immediately after successfully queuing the join operation but before attempting to copy data back to user space via copy_to_user. This design choice created a critical window of vulnerability where concurrent threads could execute overlapping JOIN_MCAST calls targeting the same address. If two such calls occurred simultaneously with identical addresses, it was possible for a second thread's join request to insert its CMA entry into the list before the first thread's corresponding leave operation had completed or even begun. This lack of serialization allowed multiple entries representing the same multicast group membership to exist concurrently within the kernel data structures, violating the expected one-to-one mapping between active joins and their internal representations.

The operational impact becomes severe when a copy_to_user failure occurs in the original joining thread. In such scenarios, the system attempts to roll back by calling rdma_leave_multicast. However, because the mutex had been dropped earlier, another thread might have already performed its own join for the same address and added an entry to the list. When the first thread's leave operation executes, it searches for a matching sockaddr and destroys the first hit it finds. Due to the race condition, this often results in destroying the newer entry rather than the one associated with the failed join. Consequently, the older worker process continues execution while holding references to ucma_multicast structures that have already been freed by the leave operation of the other thread. This use-after-free scenario leads to memory corruption and potential kernel panic or arbitrary code execution depending on how the dangling pointer is subsequently dereferenced.

This vulnerability aligns with CWE-362, which describes concurrent access resulting in a race condition, specifically manifesting as a Use After Free (CWE-416) due to improper synchronization of resource lifecycle management. From an ATT&CK perspective, this flaw could potentially be leveraged for privilege escalation or denial of service by triggering the kernel panic through crafted RDMA operations that induce copy failures while maintaining concurrent access patterns. The root cause is not merely a logic error but a failure in enforcing mutual exclusion across related state transitions and cleanup routines within the same context.

The resolution involves restructuring the locking strategy to ensure atomicity between join, user-space notification, and potential leave operations. By keeping ctx->mutex held continuously from the start of rdma_join_multicast through the copy_to_user call, the kernel prevents other threads from interleaving their own join or leave requests during this critical section. Furthermore, if a copy failure occurs, the mutex remains locked while rdma_leave_multicast is invoked to ensure that any rollback operation correctly targets and removes only the entry associated with the failed attempt rather than an unrelated concurrent one. Additionally, the logic was refined so that no leave operation is performed if the join itself failed in a way that did not publish the address to the multicast list, thereby preventing accidental destruction of valid entries belonging to other successful joins. This approach restores data integrity by ensuring that resource allocation and deallocation are strictly serialized per context, eliminating the window for race conditions.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/06/2026

Moderation

accepted

EPSS

0.00184

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!