fkie_cve-2021-47391
Vulnerability from fkie_nvd
Published
2024-05-21 15:15
Modified
2024-11-21 06:36
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests\n\nThe FSM can run in a circle allowing rdma_resolve_ip() to be called twice\non the same id_priv. While this cannot happen without going through the\nwork, it violates the invariant that the same address resolution\nbackground request cannot be active twice.\n\n       CPU 1                                  CPU 2\n\nrdma_resolve_addr():\n  RDMA_CM_IDLE -\u003e RDMA_CM_ADDR_QUERY\n  rdma_resolve_ip(addr_handler)  #1\n\n\t\t\t process_one_req(): for #1\n                          addr_handler():\n                            RDMA_CM_ADDR_QUERY -\u003e RDMA_CM_ADDR_BOUND\n                            mutex_unlock(\u0026id_priv-\u003ehandler_mutex);\n                            [.. handler still running ..]\n\nrdma_resolve_addr():\n  RDMA_CM_ADDR_BOUND -\u003e RDMA_CM_ADDR_QUERY\n  rdma_resolve_ip(addr_handler)\n    !! two requests are now on the req_list\n\nrdma_destroy_id():\n destroy_id_handler_unlock():\n  _destroy_id():\n   cma_cancel_operation():\n    rdma_addr_cancel()\n\n                          // process_one_req() self removes it\n\t\t          spin_lock_bh(\u0026lock);\n                           cancel_delayed_work(\u0026req-\u003ework);\n\t                   if (!list_empty(\u0026req-\u003elist)) == true\n\n      ! rdma_addr_cancel() returns after process_on_req #1 is done\n\n   kfree(id_priv)\n\n\t\t\t process_one_req(): for #2\n                          addr_handler():\n\t                    mutex_lock(\u0026id_priv-\u003ehandler_mutex);\n                            !! Use after free on id_priv\n\nrdma_addr_cancel() expects there to be one req on the list and only\ncancels the first one. The self-removal behavior of the work only happens\nafter the handler has returned. This yields a situations where the\nreq_list can have two reqs for the same \"handle\" but rdma_addr_cancel()\nonly cancels the first one.\n\nThe second req remains active beyond rdma_destroy_id() and will\nuse-after-free id_priv once it inevitably triggers.\n\nFix this by remembering if the id_priv has called rdma_resolve_ip() and\nalways cancel before calling it again. This ensures the req_list never\ngets more than one item in it and doesn\u0027t cost anything in the normal flow\nthat never uses this strange error path."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: aseg\u00farese de que rdma_addr_cancel() ocurra antes de emitir m\u00e1s solicitudes. El FSM puede ejecutarse en un c\u00edrculo permitiendo llamar a rdma_resolve_ip() dos veces en el mismo id_priv. Si bien esto no puede suceder sin realizar el trabajo, viola la invariante de que la misma solicitud en segundo plano de resoluci\u00f3n de direcci\u00f3n no puede estar activa dos veces. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -\u0026gt; RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): para #1 addr_handler(): RDMA_CM_ADDR_QUERY -\u0026gt; RDMA_CM_ADDR_BOUND mutex_unlock(\u0026amp;id_priv-\u0026gt;handler_mutex); [.. el controlador sigue ejecut\u00e1ndose...] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -\u0026gt; RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler)!! ahora hay dos solicitudes en la lista de solicitudes rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // Process_one_req() lo elimina autom\u00e1ticamente spin_lock_bh(\u0026amp;lock); cancel_delayed_work(\u0026amp;req-\u0026gt;trabajo); if (!list_empty(\u0026amp;req-\u0026gt;list)) == verdadero! rdma_addr_cancel() regresa despu\u00e9s de que se realiza el proceso_on_req #1 kfree(id_priv) Process_one_req(): para #2 addr_handler(): mutex_lock(\u0026amp;id_priv-\u0026gt;handler_mutex); !! El use after free en id_priv rdma_addr_cancel() espera que haya una solicitud en la lista y solo cancela la primera. El comportamiento de autoeliminaci\u00f3n del trabajo s\u00f3lo ocurre despu\u00e9s de que el manipulador ha regresado. Esto genera situaciones en las que req_list puede tener dos solicitudes para el mismo \"identificador\" pero rdma_addr_cancel() solo cancela la primera. El segundo requisito permanece activo m\u00e1s all\u00e1 de rdma_destroy_id() y usar\u00e1 id_priv despu\u00e9s de liberarlo una vez que inevitablemente se active. Solucione este problema recordando si id_priv ha llamado a rdma_resolve_ip() y cancele siempre antes de volver a llamarlo. Esto garantiza que req_list nunca obtenga m\u00e1s de un elemento y no cueste nada en el flujo normal que nunca utiliza esta extra\u00f1a ruta de error."
    }
  ],
  "id": "CVE-2021-47391",
  "lastModified": "2024-11-21T06:36:02.967",
  "metrics": {},
  "published": "2024-05-21T15:15:24.480",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.