CVE-2026-93235 in Linux
Resumen
por VulDB • 2026-09-24
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
f2fs: corrección para poner a cero los datos posteriores al EOF (End-of-File) al extender el tamaño del archivo
generic/794 4s ... - discrepancia en la salida (ver /share/git/fstests/results//generic/794.out.bad) --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 @@ -1,4 +1,16 @@ QA output created by 794 append_write +FAIL: datos no nulos en el intervalo [4080,4096) tras shutdown y remount (reinicio de montaje)
+000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< +* +001000 truncate_up ... (Ejecute 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' para ver la diferencia completa)
Se ejecutó: generic/794 Fallos: generic/794 Fallaron 1 de 1 pruebas
Pasos de generic/794: 1. escribir 4096 bytes en un archivo con valor 0x5a 2. usar fiemap para obtener el PBA (Physical Block Address / Dirección Física del Bloque) del primer bloque del archivo 3. truncar el archivo a 4080 bytes 4. desmontar; escribir 4096 bytes en el archivo con valor 0x5a directamente mediante PBA; montar de nuevo 5. extender el tamaño del archivo mediante: a) append (añadir) 4096 desde la posición offset 4096, o b) truncate hasta 8192 bytes, o c) fallocate 4096 desde la posición offset 4096 6. verificar que el intervalo [4080,4096) está puesto a cero en memoria (pagecache)
7. sincronizar rango de 4096 bytes desde offset 4096; shutdown -f (vaciar metadatos antes del apagado/shutdown) 8. desmontar; montar; verificar si [4080,4096) está puesto a cero o no.
Al extender el tamaño de un archivo (por ejemplo, mediante truncate, fallocate o write) cruzando un límite EOF (End-of-File) no alineado, es necesario asegurarse de que los datos posteriores al EOF en la página parcial se pongan a cero en el pagecache y se marquen como sucios (dirty), para luego realizar el writeback del caché y persistir los datos puestos a cero antes de confirmar el inode con i_size actualizado.
Esto ayuda a prevenir que queden expuestos datos obsoletos en disco más allá del EOF anterior tras un remount o una recuperación por fallo (crash recovery).
Dado que f2fs es un sistema de archivos LFS (Log-Structured Filesystem), solo admitimos escritura directa mediante PBA en pinfile, y pinfile tiene un tamaño de archivo alineado a secciones; por lo tanto, en Android no debería haber problemas. Sin embargo, para otros usos en entornos diferentes, solucionamos esto con la opción de montaje fsync_mode=strict.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.