CVE-2021-47391

{"id": "CVE-2021-47391", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "[email protected]", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.8, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.8}]}, "published": "2024-05-21T15:15:24.480", "references": [{"url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "[email protected]", "description": [{"lang": "en", "value": "CWE-416"}]}], "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 -> 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 -> RDMA_CM_ADDR_BOUND\n mutex_unlock(&id_priv->handler_mutex);\n [.. handler still running ..]\n\nrdma_resolve_addr():\n RDMA_CM_ADDR_BOUND -> 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(&lock);\n cancel_delayed_work(&req->work);\n\t if (!list_empty(&req->list)) == 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(&id_priv->handler_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't 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 -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): para #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. el controlador sigue ejecut\u00e1ndose...] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> 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(&lock); cancel_delayed_work(&req->trabajo); if (!list_empty(&req->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(&id_priv->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."}], "lastModified": "2025-09-23T20:16:11.397", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8ACFCEF2-6D39-4FF1-9B0F-DC8A974E6121", "versionEndExcluding": "5.10.188", "versionStartIncluding": "2.6.18"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1A437B0D-8305-4C72-B691-D26986A126CF", "versionEndExcluding": "5.14.10", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E46C74C6-B76B-4C94-A6A4-FD2FFF62D644"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "60134C3A-06E4-48C1-B04F-2903732A4E56"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0460DA88-8FE1-46A2-9DDA-1F1ABA552E71"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}