Vulnerabilidad en kernel de Linux (CVE-2024-41067)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: Scrub: maneja correctamente el error de búsqueda RST [ERROR] Al ejecutar btrfs/060 con la función RST forzada, bloquearía el siguiente ASSERT() dentro de Scrub_read_endio(): ASSERT(sector_nr < raya->nr_sectors); Antes de eso, tendríamos un volcado de árbol de btrfs_get_raid_extent_offset(), ya que no pudimos encontrar la entrada RST para el rango. [CAUSA] Dentro de Scrub_submit_extent_sector_read() cada vez que asignamos un nuevo bbio llamamos inmediatamente a btrfs_map_block() para asegurarnos de que hubiera algún rango RST que cubriera el objetivo de limpieza. Pero si btrfs_map_block()fallo, inmediatamente llamamos a endio para el bbio, mientras el bbio está recién asignado, está completamente vacío. Luego, dentro de Scrub_read_endio(), revisamos los bvecs para encontrar el número del sector (ya que bi_sector ya no es confiable si la biografía se envía a capas inferiores). Y dado que la biografía está vacía, dicha iteración de bvecs no encontraría ningún sector que coincida con el sector y devolvería sector_nr == stripe->nr_sectors, lo que activaría ASSERT(). [FIX] En lugar de llamar a btrfs_map_block() después de asignar un nuevo bbio, llame primero a btrfs_map_block(). Dado que nuestro único objetivo al llamar a btrfs_map_block() es solo actualizar stripe_len, realmente no hay necesidad de hacerlo después de btrfs_alloc_bio(). Este nuevo tiempo evitaría por completo el problema de manejar bbio vacío y, de hecho, soluciona una posible ventana de ejecuciónpara el código anterior, donde si el hilo de envío es el único propietario de pendiente_io, la limpieza nunca terminaría (ya que no lo hicimos). disminuir el contador pendiente_io). Aunque aún es necesario abordar la causa raíz del error de búsqueda de RST.