Show plain JSON{"id": "CVE-2022-49371", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-02-26T07:01:13.777", "references": [{"url": "https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/b232b02bf3c205b13a26dcec08e53baddd8e59ed", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d53a227bfcd5160ce1b61d9954901968a20651e7", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/df6de52b80aa3b46f5ac804412355ffe2e1df93e", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-667"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix deadlock in __device_attach\n\nIn __device_attach function, The lock holding logic is as follows:\n...\n__device_attach\ndevice_lock(dev) // get lock dev\n async_schedule_dev(__device_attach_async_helper, dev); // func\n async_schedule_node\n async_schedule_node_domain(func)\n entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);\n\t/* when fail or work limit, sync to execute func, but\n\t __device_attach_async_helper will get lock dev as\n\t well, which will lead to A-A deadlock. */\n\tif (!entry || atomic_read(&entry_count) > MAX_WORK) {\n\t func;\n\telse\n\t queue_work_node(node, system_unbound_wq, &entry->work)\n device_unlock(dev)\n\nAs shown above, when it is allowed to do async probes, because of\nout of memory or work limit, async work is not allowed, to do\nsync execute instead. it will lead to A-A deadlock because of\n__device_attach_async_helper getting lock dev.\n\nTo fix the deadlock, move the async_schedule_dev outside device_lock,\nas we can see, in async_schedule_node_domain, the parameter of\nqueue_work_node is system_unbound_wq, so it can accept concurrent\noperations. which will also not change the code logic, and will\nnot lead to deadlock."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: n\u00facleo del controlador: corregir un bloqueo en __device_attach En la funci\u00f3n __device_attach, la l\u00f3gica de retenci\u00f3n de bloqueo es la siguiente: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) Como se muestra arriba, cuando se permite hacer sondeos asincr\u00f3nicos, debido a falta de memoria o l\u00edmite de trabajo, no se permite el trabajo asincr\u00f3nico, para hacer la ejecuci\u00f3n sincr\u00f3nica en su lugar. conducir\u00e1 a un interbloqueo AA debido a que __device_attach_async_helper obtiene el bloqueo dev. Para solucionar el interbloqueo, mueva async_schedule_dev fuera de device_lock, como podemos ver, en async_schedule_node_domain, el par\u00e1metro de queue_work_node es system_unbound_wq, por lo que puede aceptar operaciones simult\u00e1neas. lo que tampoco cambiar\u00e1 la l\u00f3gica del c\u00f3digo y no conducir\u00e1 a un interbloqueo."}], "lastModified": "2025-04-14T20:43:02.437", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "5D0E4D0F-E8FA-4FE1-8C0B-A3401C482CE8", "versionEndExcluding": "5.4.198", "versionStartIncluding": "4.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1B42AA01-44D8-4572-95E6-FF8E374CF9C5", "versionEndExcluding": "5.10.122", "versionStartIncluding": "5.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "FC042EE3-4864-4325-BE0B-4BCDBF11AA61", "versionEndExcluding": "5.15.47", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "53E7AA2E-2FB4-45CA-A22B-08B4EDBB51AD", "versionEndExcluding": "5.17.15", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "FA6D643C-6D6A-4821-8A8D-B5776B8F0103", "versionEndExcluding": "5.18.4", "versionStartIncluding": "5.18"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}