CVE-2025-38073

{"id": "CVE-2025-38073", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "[email protected]", "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": "2025-06-18T10:15:40.720", "references": [{"url": "https://git.kernel.org/stable/c/64f505b08e0cfd8163491c8c082d4f47a88e51d4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/8c5cf440a378801d313eb58be996fdc81a8878a4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a0caf1de97e1edd7f3451f1818ea6cb970495fc5", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c0e473a0d226479e8e925d5ba93f751d8df628e9", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "[email protected]", "description": [{"lang": "en", "value": "CWE-362"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix race between set_blocksize and read paths\n\nWith the new large sector size support, it's now the case that\nset_blocksize can change i_blksize and the folio order in a manner that\nconflicts with a concurrent reader and causes a kernel crash.\n\nSpecifically, let's say that udev-worker calls libblkid to detect the\nlabels on a block device. The read call can create an order-0 folio to\nread the first 4096 bytes from the disk. But then udev is preempted.\n\nNext, someone tries to mount an 8k-sectorsize filesystem from the same\nblock device. The filesystem calls set_blksize, which sets i_blksize to\n8192 and the minimum folio order to 1.\n\nNow udev resumes, still holding the order-0 folio it allocated. It then\ntries to schedule a read bio and do_mpage_readahead tries to create\nbufferheads for the folio. Unfortunately, blocks_per_folio == 0 because\nthe page size is 4096 but the blocksize is 8192 so no bufferheads are\nattached and the bh walk never sets bdev. We then submit the bio with a\nNULL block device and crash.\n\nTherefore, truncate the page cache after flushing but before updating\ni_blksize. However, that's not enough -- we also need to lock out file\nIO and page faults during the update. Take both the i_rwsem and the\ninvalidate_lock in exclusive mode for invalidations, and in shared mode\nfor read/write operations.\n\nI don't know if this is the correct fix, but xfs/259 found it."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir ejecuci\u00f3n entre set_blocksize y las rutas de lectura Con el nuevo soporte para tama\u00f1os de sector grandes, ahora es posible que set_blocksize cambie i_blksize y el orden de los folios de forma que entre en conflicto con un lector concurrente y provoque un fallo del kernel. Espec\u00edficamente, supongamos que udev-worker llama a libblkid para detectar las etiquetas en un dispositivo de bloque. La llamada de lectura puede crear un folio de orden 0 para leer los primeros 4096 bytes del disco. Pero entonces udev es interrumpido. A continuaci\u00f3n, alguien intenta montar un sistema de archivos de tama\u00f1o de sector de 8k desde el mismo dispositivo de bloque. El sistema de archivos llama a set_blksize, que establece i_blksize en 8192 y el orden m\u00ednimo de folio en 1. Ahora udev se reanuda, a\u00fan manteniendo el folio de orden 0 que asign\u00f3. Entonces intenta programar una biograf\u00eda de lectura y do_mpage_readahead intenta crear bufferheads para el folio. Desafortunadamente, bloques_por_folio == 0 porque el tama\u00f1o de p\u00e1gina es 4096, pero el tama\u00f1o de bloque es 8192, por lo que no se conectan bufferheads y el bh walk nunca establece bdev. Luego, enviamos la biograf\u00eda con un dispositivo de bloque nulo y se produce un fallo. Por lo tanto, truncamos la cach\u00e9 de p\u00e1ginas despu\u00e9s del vaciado, pero antes de actualizar i_blksize. Sin embargo, esto no es suficiente; tambi\u00e9n necesitamos bloquear la E/S de archivos y los fallos de p\u00e1gina durante la actualizaci\u00f3n. Use tanto i_rwsem como invalidate_lock en modo exclusivo para invalidaciones y en modo compartido para operaciones de lectura/escritura. No s\u00e9 si esta sea la soluci\u00f3n correcta, pero xfs/259 la encontr\u00f3."}], "lastModified": "2025-11-14T17:04:33.980", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "95E9CB68-D623-4648-8EAD-E35B82976B1C", "versionEndExcluding": "6.6.114"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1AE98841-5774-4B45-A81C-2D188DB7E5C3", "versionEndExcluding": "6.12.31", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "A9B72DD1-715C-4101-A720-1C8D70044C06", "versionEndExcluding": "6.14.9", "versionStartIncluding": "6.13"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "8D465631-2980-487A-8E65-40AE2B9F8ED1"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "4C9D071F-B28E-46EC-AC61-22B913390211"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "13FC0DDE-E513-465E-9E81-515702D49B74"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}