CVE-2024-27080

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la ejecución al detectar rangos de delalloc durante fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, esto introdujo una ejecución que nos hace perder rangos de delalloc para regiones de archivos que actualmente están vacías, por lo que quien llama a fiemap no sabrá que hay datos para algunas regiones de archivos. Esto puede ser bastante grave en algunos casos de uso; por ejemplo, en las versiones de Coreutils anteriores a la 9.0, el programa cp utilizaba fiemap para detectar agujeros y datos en el archivo de origen, copiando solo regiones con datos (extensiones o delalloc) del archivo de origen al destino. archivo para preservar los agujeros (consulte la documentación para conocer su opción de línea de comando --sparse). Esto significa que si se usó cp con un archivo de origen que tenía delalloc en un agujero, el archivo de destino podría terminar sin esos datos, lo que efectivamente es un problema de pérdida de datos, si llegara a la ejecución que se describe a continuación. La ejecución ocurre así: 1) Se llama a Fiemap, sin el indicador FIEMAP_FLAG_SYNC, para un archivo que tiene delalloc en el rango de archivos [64M, 65M[, que actualmente es un agujero; 2) Fiemap bloquea el inodo en modo compartido, luego comienza a iterar el árbol de subvolumen del inodo buscando elementos de extensión de archivo, sin tener todo el rango objetivo de fiemap bloqueado en el árbol io del inodo - el cambio introducido recientemente por el commit b0ad381fa769 ("btrfs: fix deadlock" con fiemap y bloqueo de extensión"). Solo bloquea rangos en el árbol io cuando encuentra un agujero o una extensión de asignación previa desde esa confirmación; 3) Tenga en cuenta que fiemap clona cada hoja antes de usarla, y esto es para evitar interbloqueos al bloquear un rango de archivos en el árbol io del inodo y el búfer de fiemap está asignado en memoria a algún archivo, porque escribir en la página con btrfs_page_mkwrite() esperará en cualquier extensión ordenada para el rango de la página y la extensión ordenada necesita bloquear el rango y puede necesitar modificar la misma hoja, lo que lleva a un punto muerto en la hoja; 4) Mientras se iteran los elementos de extensión del archivo en la hoja clonada antes de encontrar el hueco en el rango [64M, 65M[, la delalloc en ese rango se vacía y su extensión ordenada se completa, lo que significa que el elemento de extensión del archivo correspondiente está en el árbol de subvolumen del inodo. , pero no está presente en la hoja clonada sobre la que fiemap está iterando; 5) Cuando fiemap encuentra el agujero en el rango [64M, 65M[ al ver el espacio en la hoja clonada (o un elemento de extensión de archivo con disk_bytenr == 0 en caso de que la función NO_HOLES no esté habilitada), bloqueará ese rango de archivos. en el árbol io del inodo y luego busque delalloc verificando el bit EXTENT_DELALLOC en el árbol io para ese rango y extensiones ordenadas (con btrfs_find_delalloc_in_range()). Pero no encuentra nada ya que la delalloc en ese rango ya se vació y la extensión ordenada se completó y desapareció; como resultado, fiemap no informará que hay delalloc o una extensión para el rango [64M, 65M[, por lo que el espacio del usuario será engañoso a pensar que hay un agujero en ese rango. En realidad, esto podría activarse esporádicamente con el caso de prueba generic/094 de fstests, que informa que falta un rango de extensión/delalloc como este: generic/094 2s ... - falta de coincidencia de salida (consulte /home/fdmanana/git/hub/xfstests/results //generic/094.out.bad) ---truncado---