CVE-2024-43892

{"id": "CVE-2024-43892", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 4.7, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.0}]}, "published": "2024-08-26T11:15:04.157", "references": [{"url": "https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/912736a0435ef40e6a4ae78197ccb5553cb80b05", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9972605a238339b85bd16b084eed5f18414d22db", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: protect concurrent access to mem_cgroup_idr\n\nCommit 73f576c04b94 (\"mm: memcontrol: fix cgroup creation failure after\nmany small jobs\") decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures. It introduced IDR to maintain the memcg ID\nspace. The IDR depends on external synchronization mechanisms for\nmodifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications. However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero. Fix that.\n\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time. These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode. Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block's list_lru didn't have list_lru_one for the\nmemcg of that object. The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success. No evidence were found for these cases.\n\nLooking more deeply, we started seeing situations where valid memcg's id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them. So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove(). These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them. Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: protege el acceso simult\u00e1neo a mem_cgroup_idr. el commit 73f576c04b94 (\"mm: memcontrol: repara el error de creaci\u00f3n de cgroup despu\u00e9s de muchos trabajos peque\u00f1os\") desacopla los ID de memcg del espacio de ID de CSS para reparar el cgroup. fracasos de la creaci\u00f3n. Introdujo IDR para mantener el espacio de identificaci\u00f3n de memcg. El IDR depende de mecanismos externos de sincronizaci\u00f3n para las modificaciones. Para mem_cgroup_idr, idr_alloc() e idr_replace() ocurren dentro de la devoluci\u00f3n de llamada CSS y, por lo tanto, est\u00e1n protegidos a trav\u00e9s de cgroup_mutex contra modificaciones simult\u00e1neas. Sin embargo, idr_remove() para mem_cgroup_idr no estaba protegido contra la concurrencia y se puede ejecutar simult\u00e1neamente para diferentes memcgs cuando alcanzan su referencia a cero. Arregla eso. Hemos estado viendo fallas del kernel basadas en list_lru con baja frecuencia en nuestra flota durante mucho tiempo. Estos fallos se produjeron en diferentes partes del c\u00f3digo list_lru, incluidos list_lru_add(), list_lru_del() y el c\u00f3digo de reparaci\u00f3n. Tras una inspecci\u00f3n m\u00e1s detallada, parec\u00eda que para un objeto determinado (dentry e inodo), el list_lru del super_block no ten\u00eda list_lru_one para el memcg de ese objeto. Las sospechas iniciales fueron que el objeto no estaba asignado a trav\u00e9s de kmem_cache_alloc_lru() o de alguna manera memcg_list_lru_alloc() no pudo asignar list_lru_one() para un memcg pero devolvi\u00f3 el \u00e9xito. No se encontraron pruebas de estos casos. Mirando m\u00e1s profundamente, comenzamos a ver situaciones en las que la identificaci\u00f3n de memcg v\u00e1lida no est\u00e1 presente en mem_cgroup_idr y, en algunos casos, varios memcg v\u00e1lidos tienen la misma identificaci\u00f3n y mem_cgroup_idr apunta a uno de ellos. Entonces, la explicaci\u00f3n m\u00e1s razonable es que estas situaciones pueden ocurrir debido a la ejecuci\u00f3n entre m\u00faltiples llamadas idr_remove() o la ejecuci\u00f3n entre idr_alloc()/idr_replace() e idr_remove(). Estas ejecuciones est\u00e1n provocando que varios memcgs adquieran el mismo ID y luego desconectar uno de ellos limpiar\u00eda list_lrus en el sistema para todos ellos. El acceso posterior desde otros memcgs a list_lru provoca bloqueos debido a que falta list_lru_one."}], "lastModified": "2024-09-12T12:15:49.593", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "ACA5323A-A089-48EF-85AA-99E8DF835386", "versionEndExcluding": "6.6.46", "versionStartIncluding": "4.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D074AE50-4A5E-499C-A2FD-75FD60DEA560", "versionEndExcluding": "6.10.5", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8B3CE743-2126-47A3-8B7C-822B502CF119"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4DEB27E7-30AA-45CC-8934-B89263EF3551"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}