FKIE_CVE-2021-47391

Vulnerability from fkie_nvd - Published: 2024-05-21 15:15 - Updated: 2026-08-04 10:17
Severity
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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/03d884671572af8bcfbc9e63944c1021efce7589Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2aPatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2aPatch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *
linux linux_kernel 5.15
linux linux_kernel 5.15
linux linux_kernel 5.15
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/infiniband/core/cma.c",
            "drivers/infiniband/core/cma_priv.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "9a085fa9b7d644a234465091e038c1911e1a4f2a",
              "status": "affected",
              "version": "e51060f08a61965c4dd91516d82fe90617152590",
              "versionType": "git"
            },
            {
              "lessThan": "03d884671572af8bcfbc9e63944c1021efce7589",
              "status": "affected",
              "version": "e51060f08a61965c4dd91516d82fe90617152590",
              "versionType": "git"
            },
            {
              "lessThan": "305d568b72f17f674155a2a8275f865f207b3808",
              "status": "affected",
              "version": "e51060f08a61965c4dd91516d82fe90617152590",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/infiniband/core/cma.c",
            "drivers/infiniband/core/cma_priv.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.18"
            },
            {
              "lessThan": "2.6.18",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.188",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.14.*",
              "status": "unaffected",
              "version": "5.14.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "8ACFCEF2-6D39-4FF1-9B0F-DC8A974E6121",
              "versionEndExcluding": "5.10.188",
              "versionStartIncluding": "2.6.18",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "1A437B0D-8305-4C72-B691-D26986A126CF",
              "versionEndExcluding": "5.14.10",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "E46C74C6-B76B-4C94-A6A4-FD2FFF62D644",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:*",
              "matchCriteriaId": "60134C3A-06E4-48C1-B04F-2903732A4E56",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc3:*:*:*:*:*:*",
              "matchCriteriaId": "0460DA88-8FE1-46A2-9DDA-1F1ABA552E71",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "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": "2026-08-04T10:17:01.443",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2021-47391",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-05-21T17:33:43.729564Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-05-21T15:15:24.480",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.