CVE-2025-40303 in Linux
Resumen
por VulDB • 2026-05-27
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
btrfs: garantizar que no se escriban de nuevo los metadatos sucios para un sistema de archivos con errores
[BUG]
Durante el desarrollo de una característica menor (asegurar que se llame a btrfs_bio::end_io() en el contexto de la tarea), noté un bloqueo en generic/388, donde las escrituras de metadatos desencadenaban nuevos trabajos después de btrfs_stop_all_workers().
Resulta que esto puede ocurrir incluso sin ninguna modificación de código, simplemente usando RAID5 para los metadatos y la misma carga de trabajo de generic/388 desencadenará el uso después de la liberación (use-after-free).
[CAUSA]
Si btrfs encuentra un error, el sistema de archivos se marca como erróneo, no se permite ninguna nueva transacción, por lo que los metadatos están en un estado congelado.
Pero hay algunas modificaciones de metadatos antes de ese error, y todavía están en la caché de páginas del inode del btree.
Dado que no habrá una confirmación real de la transacción, todos esos folios sucios se mantienen tal cual en la caché de páginas, y no pueden ser invalidados por la llamada invalidate_inode_pages2() dentro de close_ctree(), porque están sucios.
Y finalmente, después de btrfs_stop_all_workers(), llamamos a iput() en el inode del btree, lo que desencadena la escritura de vuelta de esos metadatos sucios.
Y si el sistema de archivos está utilizando metadatos RAID56, esto desencadenará una operación de lectura-modificación-escritura (RMW) y colgará nuevos trabajos en rmw_workers, que ya está detenido, causando una advertencia de queue_work() y uso después de la liberación (use-after-free).
[SOLUCIÓN]
Añadir un manejo especial para write_one_eb(), de modo que si el sistema de archivos ya está en un estado de error, marcar inmediatamente el bbio como fallo, en lugar de enviarlos realmente.
Luego, durante close_ctree(), iput() simplemente descartará todos esos bloques de árbol sucios sin escribirlos realmente de nuevo, por lo que no habrá más nuevos trabajos para las colas de trabajo ya detenidas y liberadas.
El descarte adicional en write_one_eb() también actúa como una red de seguridad adicional. Por ejemplo, la abortación de la transacción es desencadenada por algunas corrupciones del árbol de extents/espacio libre, y dado que el árbol de extents/espacio libre ya está corrupto, algunos bloques de árbol pueden ser asignados donde no deberían estar (sobrescribiendo bloques de árbol existentes). En ese caso, escribirlos de nuevo corrompería aún más el sistema de archivos.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.