CVE-2024-49878

{"id": "CVE-2024-49878", "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": "2024-10-21T18:15:09.863", "references": [{"url": "https://git.kernel.org/stable/c/06ff97a20b8c9e9d256b0d2c3e87f78f8ccea3de", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/1d5f85f1b7db79c75c9e07d6571ce2a7bdf725c4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/333fbaf6864a4ca031367eb947961a1f3484d337", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/393331e16ce205e036e58b3d8ca4ee2e635f21d9", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/4b90d2eb451b357681063ba4552b10b39d7ad885", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8a6fef7d22a1d952aed68584d3fcc0d018d2bdc3", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/927abc5b7d6d2c2e936bec5a2f71d9512c5e72f7", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/b4afe4183ec77f230851ea139d91e5cf2644c68b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "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\nresource: fix region_intersects() vs add_memory_driver_managed()\n\nOn a system with CXL memory, the resource tree (/proc/iomem) related to\nCXL memory may look like something as follows.\n\n490000000-50fffffff : CXL Window 0\n 490000000-50fffffff : region0\n 490000000-50fffffff : dax0.0\n 490000000-50fffffff : System RAM (kmem)\n\nBecause drivers/dax/kmem.c calls add_memory_driver_managed() during\nonlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL\nWindow X\". This confuses region_intersects(), which expects all \"System\nRAM\" resources to be at the top level of iomem_resource. This can lead to\nbugs.\n\nFor example, when the following command line is executed to write some\nmemory in CXL memory range via /dev/mem,\n\n $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1\n dd: error writing '/dev/mem': Bad address\n 1+0 records in\n 0+0 records out\n 0 bytes copied, 0.0283507 s, 0.0 kB/s\n\nthe command fails as expected. However, the error code is wrong. It\nshould be \"Operation not permitted\" instead of \"Bad address\". More\nseriously, the /dev/mem permission checking in devmem_is_allowed() passes\nincorrectly. Although the accessing is prevented later because ioremap()\nisn't allowed to map system RAM, it is a potential security issue. During\ncommand executing, the following warning is reported in the kernel log for\ncalling ioremap() on system RAM.\n\n ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff\n WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d\n Call Trace:\n memremap+0xcb/0x184\n xlate_dev_mem_ptr+0x25/0x2f\n write_mem+0x94/0xfb\n vfs_write+0x128/0x26d\n ksys_write+0xac/0xfe\n do_syscall_64+0x9a/0xfd\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe details of command execution process are as follows. In the above\nresource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a\ntop level resource. So, region_intersects() will report no System RAM\nresources in the CXL memory region incorrectly, because it only checks the\ntop level resources. Consequently, devmem_is_allowed() will return 1\n(allow access via /dev/mem) for CXL memory region incorrectly. \nFortunately, ioremap() doesn't allow to map System RAM and reject the\naccess.\n\nSo, region_intersects() needs to be fixed to work correctly with the\nresource tree with \"System RAM\" not at top level as above. To fix it, if\nwe found a unmatched resource in the top level, we will continue to search\nmatched resources in its descendant resources. So, we will not miss any\nmatched resources in resource tree anymore.\n\nIn the new implementation, an example resource tree\n\n|------------- \"CXL Window 0\" ------------|\n|-- \"System RAM\" --|\n\nwill behave similar as the following fake resource tree for\nregion_intersects(, IORESOURCE_SYSTEM_RAM, ),\n\n|-- \"System RAM\" --||-- \"CXL Window 0a\" --|\n\nWhere \"CXL Window 0a\" is part of the original \"CXL Window 0\" that\nisn't covered by \"System RAM\"."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: recurso: corregir region_intersects() frente a add_memory_driver_managed() En un sistema con memoria CXL, el \u00e1rbol de recursos (/proc/iomem) relacionado con la memoria CXL puede parecerse a lo siguiente. 490000000-50fffffff: CXL Window 0 490000000-50fffffff: region0 490000000-50fffffff: dax0.0 490000000-50fffffff: RAM del sistema (kmem) Debido a que drivers/dax/kmem.c llama a add_memory_driver_managed() durante la conexi\u00f3n en l\u00ednea de la memoria CXL, lo que hace que \"System RAM (kmem)\" sea un descendiente de \"CXL Window X\". Esto confunde a region_intersects(), que espera que todos los recursos de \"RAM del sistema\" est\u00e9n en el nivel superior de iomem_resource. Esto puede provocar errores. Por ejemplo, cuando se ejecuta la siguiente l\u00ednea de comando para escribir algo de memoria en el rango de memoria CXL a trav\u00e9s de /dev/mem, $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copies, 0.0283507 s, 0.0 kB/s el comando falla como se esperaba. Sin embargo, el c\u00f3digo de error es incorrecto. Deber\u00eda ser \"Operaci\u00f3n no permitida\" en lugar de \"Direcci\u00f3n incorrecta\". M\u00e1s grave a\u00fan, la comprobaci\u00f3n de permisos de /dev/mem en devmem_is_allowed() pasa incorrectamente. Aunque el acceso se impide m\u00e1s tarde porque ioremap() no tiene permiso para mapear la RAM del sistema, es un problema de seguridad potencial. Durante la ejecuci\u00f3n del comando, se informa la siguiente advertencia en el registro del n\u00facleo por llamar a ioremap() en la RAM del sistema. ioremap en RAM en 0x0000000490000000 - 0x0000000490000fff ADVERTENCIA: CPU: 2 PID: 416 en arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Rastreo de llamadas: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 Los detalles del proceso de ejecuci\u00f3n del comando son los siguientes. En el \u00e1rbol de recursos anterior, \"System RAM\" es un descendiente de \"CXL Window 0\" en lugar de un recurso de nivel superior. Por lo tanto, region_intersects() no informar\u00e1 de forma incorrecta ning\u00fan recurso de System RAM en la regi\u00f3n de memoria CXL, porque solo comprueba los recursos de nivel superior. En consecuencia, devmem_is_allowed() devolver\u00e1 1 (permitir\u00e1 el acceso a trav\u00e9s de /dev/mem) para la regi\u00f3n de memoria CXL de forma incorrecta. Afortunadamente, ioremap() no permite mapear System RAM y rechazar el acceso. Por lo tanto, es necesario corregir region_intersects() para que funcione correctamente con el \u00e1rbol de recursos con \"System RAM\" no en el nivel superior como se indica anteriormente. Para corregirlo, si encontramos un recurso no coincidente en el nivel superior, continuaremos buscando recursos coincidentes en sus recursos descendientes. Por lo tanto, ya no nos perderemos ning\u00fan recurso coincidente en el \u00e1rbol de recursos. En la nueva implementaci\u00f3n, un \u00e1rbol de recursos de ejemplo |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| se comportar\u00e1 de manera similar al siguiente \u00e1rbol de recursos falso para region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"RAM del sistema\" --||-- \"Ventana CXL 0a\" --| Donde \"Ventana CXL 0a\" es parte de la \"Ventana CXL 0\" original que no est\u00e1 cubierta por la \"RAM del sistema\"."}], "lastModified": "2024-11-13T14:32:13.227", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AD732A27-BE8B-4786-B27A-0C7AEF3D4588", "versionEndExcluding": "5.10.227", "versionStartIncluding": "5.1"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4D51C05D-455B-4D8D-89E7-A58E140B864C", "versionEndExcluding": "5.15.168", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D01BD22E-ACD1-4618-9D01-6116570BE1EE", "versionEndExcluding": "6.1.113", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E90B9576-56C4-47BC-AAB0-C5B2D438F5D0", "versionEndExcluding": "6.6.55", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4C16BCE0-FFA0-4599-BE0A-1FD65101C021", "versionEndExcluding": "6.10.14", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9", "versionEndExcluding": "6.11.3", "versionStartIncluding": "6.11"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}