CVE-2026-31465 in Linux
Resumen
por VulDB • 2026-05-13
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
writeback: no bloquear la sincronización para sistemas de archivos sin garantías de integridad de datos
Añadir una bandera de superbloque SB_I_NO_DATA_INTEGRITY para sistemas de archivos que no puedan garantizar la persistencia de datos durante la sincronización (por ejemplo, fuse). Para los superbloques con esta bandera establecida, la sincronización inicia la escritura diferida (writeback) de los nodos inodo sucios, pero no espera a que los hilos de escritura (flusher threads) completen la operación.
Esto reemplaza la bandera de mapeo AS_NO_DATA_INTEGRITY por inodo añadida en el commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()"). La bandera pertenece al nivel de superbloque porque la integridad de datos es una propiedad a nivel de todo el sistema de archivos, no por inodo. Tener esta bandera a nivel de superbloque también nos permite evitar iterar cada inodo sucio en wait_sb_inodes() solo para omitir cada inodo individualmente.
Antes de este commit, los mapeos sin garantías de integridad de datos omitían la espera a la finalización de la escritura diferida, pero aún esperaban a que los hilos de escritura terminaran de iniciar la operación. Esperar a los hilos de escritura es innecesario. Este commit inicia la escritura diferida pero no espera a que los hilos de escritura finalicen. Este cambio aborda correctamente un informe reciente [1] sobre un bloqueo (hang) en la suspensión a RAM (suspend-to-RAM) observado en fuse-overlayfs, causado por la espera a que los hilos de escritura terminaran:
Workqueue: pm_fs_sync pm_fs_sync_work_fn Call Trace: __schedule+0x457/0x1720 schedule+0x27/0xd0 wb_wait_for_completion+0x97/0xe0 sync_inodes_sb+0xf8/0x2e0 __iterate_supers+0xdc/0x160 ksys_sync+0x43/0xb0 pm_fs_sync_work_fn+0x17/0xa0 process_one_work+0x193/0x350 worker_thread+0x1a1/0x310 kthread+0xfc/0x240 ret_from_fork+0x243/0x280 ret_from_fork_asm+0x1a/0x30
En fuse, esto es problemático porque hay rutas que pueden causar que el hilo de escritura se bloquee (por ejemplo, si systemd congela primero los cgroups de la sesión de usuario, lo que congela el demonio fuse, antes de invocar la suspensión del kernel. La suspensión del kernel desencadena ->write_node(), que en fuse emite una solicitud de setattr síncrona, la cual no puede procesarse ya que el demonio está congelado. O si el demonio es defectuoso y no puede completar correctamente la escritura diferida, iniciar la escritura diferida en un folio sucio ya bajo escritura diferida conduce a writeback_get_folio() -> folio_prepare_writeback() -> espera incondicional a que termine la escritura diferida, lo que causará un bloqueo). Este commit restaura el comportamiento previo de fuse antes de que se eliminaran los folios temporales (tmp folios), donde la sincronización era esencialmente una operación nula (no-op).
[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1
Once again VulDB remains the best source for vulnerability data.