In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.
       CPU 1                                  CPU 2
rdma_resolve_addr():
  RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)  #1
			 process_one_req(): for #1
                          addr_handler():
                            RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
                            mutex_unlock(&id_priv->handler_mutex);
                            [.. handler still running ..]
rdma_resolve_addr():
  RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)
    !! two requests are now on the req_list
rdma_destroy_id():
 destroy_id_handler_unlock():
  _destroy_id():
   cma_cancel_operation():
    rdma_addr_cancel()
                          // process_one_req() self removes it
		          spin_lock_bh(&lock);
                           cancel_delayed_work(&req->work);
	                   if (!list_empty(&req->list)) == true
      ! rdma_addr_cancel() returns after process_on_req #1 is done
   kfree(id_priv)
			 process_one_req(): for #2
                          addr_handler():
	                    mutex_lock(&id_priv->handler_mutex);
                            !! Use after free on id_priv
rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
only cancels the first one.
The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn't cost anything in the normal flow
that never uses this strange error path.
                
            Metrics
Affected Vendors & Products
References
        History
                    Tue, 23 Sep 2025 20:30:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Weaknesses | CWE-416 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.15:rc3:*:*:*:*:*:* | |
| Metrics | cvssV3_1 
 | cvssV3_1 
 | 
Mon, 04 Nov 2024 12:15:00 +0000
| Type | Values Removed | Values Added | 
|---|---|---|
| Metrics | ssvc 
 | 
 MITRE
                        MITRE
                    Status: PUBLISHED
Assigner: Linux
Published: 2024-05-21T15:03:49.545Z
Updated: 2025-05-04T07:10:00.803Z
Reserved: 2024-05-21T14:58:30.813Z
Link: CVE-2021-47391
 Vulnrichment
                        Vulnrichment
                    Updated: 2024-08-04T05:39:59.044Z
 NVD
                        NVD
                    Status : Analyzed
Published: 2024-05-21T15:15:24.480
Modified: 2025-09-23T20:16:11.397
Link: CVE-2021-47391
 Redhat
                        Redhat