Skip to content
CVE PROGRAM SOURCE RECORD7.8 High

CVE-2021-47391

RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests

Description

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.

Affected products

Version statuses are supplied by the assigning organization. Consult the original record for detailed ranges and platform conditions.

Linux Linux

Default version status: unaffected

  • e51060f08a61965c4dd91516d82fe90617152590 to < 9a085fa9b7d644a234465091e038c1911e1a4f2aaffected
  • e51060f08a61965c4dd91516d82fe90617152590 to < 03d884671572af8bcfbc9e63944c1021efce7589affected
  • e51060f08a61965c4dd91516d82fe90617152590 to < 305d568b72f17f674155a2a8275f865f207b3808affected

Linux Linux

Default version status: affected

  • 2.6.18affected
  • 0 to < 2.6.18unaffected
  • 5.10.188 to ≤ 5.10.*unaffected
  • 5.14.10 to ≤ 5.14.*unaffected
  • 5.15 to ≤ *unaffected

References