CVE-2021-46989

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hfsplus: evita la corrupción al reducir y truncar Creo que hay algunos problemas introducidos por el commit 31651c607151 ("hfsplus: evita el punto muerto en el truncamiento de archivos") HFS+ tiene registros de extensión que siempre contienen 8 extensiones. En caso de que el primer registro de extensión en el archivo de catálogo se llene, se asignan nuevos registros desde el archivo de desbordamiento de extensiones. En caso de que se produzca un truncamiento reducido en la mitad de un registro de extensión que se ubica en un archivo de desbordamiento de extensiones, la lógica en hfsplus_file_truncate() se cambió para que la llamada a hfs_brec_remove() ya no esté protegida. La acción correcta sería simplemente liberar las extensiones que exceden el nuevo tamaño dentro del registro de extensión llamando a hfsplus_free_extents() y luego verificar si se debe eliminar todo el registro de extensión. Sin embargo, dado que la guardia (blk_cnt > start) está ahora después de la llamada a hfs_brec_remove(), esto tiene el efecto desafortunado de que el último registro de extensión coincidente se elimina incondicionalmente. Para reproducir este problema, cree un archivo que tenga al menos 10 extensiones y luego realice un truncamiento reducido hasta la mitad del último registro de extensión, de modo que el número de extensiones restantes no sea menor o divisible por 8. Esto hace que el último registro de extensión ( 8 extensiones) para eliminarse por completo en lugar de truncarse a la mitad. Por tanto, esto provoca corrupción y pérdida de datos. La solución para esto es simplemente verificar si el nuevo final truncado está debajo del inicio de este registro de extensión, lo que hace que sea seguro eliminar el registro de extensión completo. Sin embargo, la llamada a hfs_brec_remove() no se puede mover a su lugar anterior ya que estamos eliminando ->tree_lock y puede provocar una condición de ejecución y la invalidación de la información almacenada en caché, posiblemente corrompiendo los datos del nodo. Otro tema está relacionado con éste. Al ingresar al bloque (blk_cnt > start) no mantenemos ->tree_lock. Salimos del bucle sin mantener el bloqueo, pero hfs_find_exit() lo desbloquea. No estoy seguro de si es posible que otra persona tome el bloqueo bajo nuestros pies, pero puede causar errores difíciles de depurar y desbloqueo prematuro. Aunque no exista ningún riesgo real, el bloqueo siempre debe mantenerse en equilibrio. Tomando así el candado ahora justo antes del control.