CVE-2024-47736

{"id": "CVE-2024-47736", "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-21T13:15:03.737", "references": [{"url": "https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Modified", "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\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it's formed with\nseveral overlapped big pclusters as below:\n\n Ext: logical offset | length : physical offset | length\n 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384\n 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384\n 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384\n...\n\nHere, extent 0/1 are physically overlapped although it's entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete. If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues. However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries. However, this is somewhat hard to implement\neasily if overlapped big pclusters exist. Again, these only appear in\nfuzzed images so let's simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn't be any\ndifference."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: manejar pclusters superpuestos fuera de im\u00e1genes manipuladas correctamente syzbot inform\u00f3 un problema de bloqueo de tareas debido a un caso de interbloqueo donde est\u00e1 esperando el bloqueo de folio de un folio en cach\u00e9 que se usar\u00e1 para E/S de cach\u00e9. Despu\u00e9s de mirar la imagen difusa creada, encontr\u00e9 que est\u00e1 formada con varios pclusters grandes superpuestos como se muestra a continuaci\u00f3n: Ext: desplazamiento l\u00f3gico | longitud: desplazamiento f\u00edsico | longitud 0: 0.. 16384 | 16384: 151552.. 167936 | 16384 1: 16384.. 32768 | 16384: 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Aqu\u00ed, las extensiones 0/1 est\u00e1n f\u00edsicamente superpuestas, aunque es completamente _impossible_ para las im\u00e1genes de sistemas de archivos normales generadas por mkfs. Primero, los folios administrados que contienen datos comprimidos se marcar\u00e1n como actualizados y luego se desbloquear\u00e1n inmediatamente (a diferencia de los folios locales) cuando se completen las E/S comprimidas. Si los bloques f\u00edsicos no se env\u00edan en el orden incremental, debe haber BIO separados para evitar problemas de dependencia. Sin embargo, el c\u00f3digo actual organiza mal z_erofs_fill_bio_vec() y el env\u00edo de BIO, lo que causa esperas inesperadas de BIO. En segundo lugar, los folios administrados se conectar\u00e1n a sus propios pclusters para realizar consultas entre consultas eficientes. Sin embargo, esto es algo dif\u00edcil de implementar f\u00e1cilmente si existen pclusters grandes superpuestos. Nuevamente, estos solo aparecen en im\u00e1genes difusas, por lo que simplemente retrocedamos a p\u00e1ginas temporales de corta duraci\u00f3n para que sean correctas. Adem\u00e1s, justifica que los folios administrados referenciados no se pueden truncar por ahora y revierte parte de el commit 2080ca1ed3e4 (\"erofs: ordenar `struct z_erofs_bvec`\") para simplificar, aunque no deber\u00eda haber ninguna diferencia."}], "lastModified": "2025-01-17T14:15:31.577", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0FF7E6C3-354F-4036-93CB-2EE747BC3E8B", "versionEndExcluding": "6.10.13", "versionStartIncluding": "5.13"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AB755D26-97F4-43B6-8604-CD076811E181", "versionEndExcluding": "6.11.2", "versionStartIncluding": "6.11"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}