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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontré el siguiente pánico con generic/648 en btrfs_holes_spacecache. error de aserción: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aquí ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: < TAREA> extensión_write_cache_pages+0x2ac/0x8f0 extensión_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en caché en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensión. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la raíz de confirmación para evitar un punto muerto con el árbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el caché de espacio, encontramos un error y, en caso de error, descartamos la asignación de extensión. Esto es normal para archivos normales, pero el inodo de caché de espacio libre es especial. Siempre esperamos que el mapa de extensión sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensión falso. Dado que estamos desaprobando esta función, la forma más sencilla de solucionarlo es simplemente omitir la eliminación del rango del mapa de extensión para este rango fallido. Acorté la prueba usando inyección de error para enfatizar el área y facilitar su reproducción. Con este parche implementado, ya no entraremos en pánico con mi prueba de inyección de errores.