CVE-2023-52786

{"id": "CVE-2023-52786", "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-05-21T16:15:17.413", "references": [{"url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc", "tags": ["Patch"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "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\next4: fix racy may inline data check in dio write\n\nsyzbot reports that the following warning from ext4_iomap_begin()\ntriggers as of the commit referenced below:\n\n if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\n return -ERANGE;\n\nThis occurs during a dio write, which is never expected to encounter\nan inode with inline data. To enforce this behavior,\next4_dio_write_iter() checks the current inline state of the inode\nand clears the MAY_INLINE_DATA state flag to either fall back to\nbuffered writes, or enforce that any other writers in progress on\nthe inode are not allowed to create inline data.\n\nThe problem is that the check for existing inline data and the state\nflag can span a lock cycle. For example, if the ilock is originally\nlocked shared and subsequently upgraded to exclusive, another writer\nmay have reacquired the lock and created inline data before the dio\nwrite task acquires the lock and proceeds.\n\nThe commit referenced below loosens the lock requirements to allow\nsome forms of unaligned dio writes to occur under shared lock, but\nAFAICT the inline data check was technically already racy for any\ndio write that would have involved a lock cycle. Regardless, lift\nclearing of the state bit to the same lock critical section that\nchecks for preexisting inline data on the inode to close the race."}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ext4: corrige la verificaci\u00f3n de datos en l\u00ednea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmaci\u00f3n a la que se hace referencia a continuaci\u00f3n: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en l\u00ednea. Para imponer este comportamiento, ext4_dio_write_iter() verifica el estado en l\u00ednea actual del inodo y borra el indicador de estado MAY_INLINE_DATA para volver a las escrituras almacenadas en el b\u00fafer o imponer que otros escritores en progreso en el inodo no puedan crear datos en l\u00ednea. El problema es que la verificaci\u00f3n de datos en l\u00ednea existentes y la bandera de estado puede abarcar un ciclo de bloqueo. Por ejemplo, si el ilock originalmente estaba bloqueado como compartido y posteriormente actualizado a exclusivo, es posible que otro escritor haya vuelto a adquirir el bloqueo y haya creado datos en l\u00ednea antes de que la tarea de escritura dio adquiera el bloqueo y contin\u00fae. El compromiso al que se hace referencia a continuaci\u00f3n afloja los requisitos de bloqueo para permitir que se produzcan algunas formas de escrituras de dio no alineadas bajo un bloqueo compartido, pero AFAICT, la verificaci\u00f3n de datos en l\u00ednea t\u00e9cnicamente ya era picante para cualquier escritura de dio que hubiera involucrado un ciclo de bloqueo. De todos modos, limpie el bit de estado en la misma secci\u00f3n cr\u00edtica de bloqueo que verifica si hay datos en l\u00ednea preexistentes en el inodo para cerrar la ejecuci\u00f3n."}], "lastModified": "2025-09-25T16:34:49.327", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "40185741-377D-4584-81B4-36CD74A91AD7", "versionEndExcluding": "6.5.13", "versionStartIncluding": "6.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "B58252FA-A49C-411F-9B28-DC5FE44BC5A0", "versionEndExcluding": "6.6.3", "versionStartIncluding": "6.6"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}