Por Canuto  

El kernel Linux 7.3 incorpora una corrección para el controlador de sistemas de archivos FAT que durante años aceptó nombres de archivo más largos de lo permitido, truncándolos silenciosamente y provocando comportamientos inesperados. El bug, descubierto por un ingeniero de Huawei, afectaba la integridad de los datos y generaba alertas del kernel al usar funciones como open(), aunque vfat no está comprometido.
***

  • Fallo crítico: el controlador FAT de Linux no verificaba el límite superior de longitud de nombres, truncando en silencio los que superaban 255 bytes.
  • Riesgo potencial: el problema podía causar advertencias del kernel y asignar inodos incorrectos, comprometiendo la integridad de los datos.
  • Solución: el parche de Huawei agrega una verificación de NAME_MAX en msdos_format_name(), alineándose con otros sistemas de archivos.

Un bug silencioso en el corazón de FAT

El controlador de sistema de archivos FAT de Linux, encargado de dar soporte a FAT12, FAT16 y FAT32, rara vez recibe actualizaciones relevantes, pero para Linux 7.3 llegó un parche que corrige un comportamiento defectuoso que podía pasar desapercibido durante mucho tiempo. El problema residía en la falta de una verificación de límite superior en la longitud de los nombres de archivo, lo que permitía que nombres demasiado largos se truncaran silenciosamente, generando situaciones inesperadas.

Cuando un nombre de archivo excedía el límite NAME_MAX de Linux, que es de 255 bytes, el controlador truncaba el exceso de longitud sin emitir ninguna advertencia y continuaba como si la operación hubiese tenido éxito. Este comportamiento no era intencionado, ya que al leer posteriormente esos archivos, el sistema solo coincidía con los bytes truncados, lo que podía llevar a inconsistencias y a una posible pérdida de datos.

El ingeniero de Huawei Zizhi Wo fue quien detectó y solventó el problema en el controlador FAT, explicando en el mensaje del parche que la función `msdos_format_name()` no realizaba ninguna verificación de límite superior en la longitud del nombre de entrada.

Según Wo, silenciosamente truncaba un nombre arbitrariamente largo a la forma 8.3 (11 bytes) y devolvía éxito, mientras que la posterior `fat_scan()` solo coincidía con esos 11 bytes truncados, por lo que devolvía un inodo siempre que existiera en el disco una entrada con el mismo nombre 8.3.

El riesgo con nombres extremadamente largos

Para ilustrar la gravedad del fallo, Wo puso un ejemplo concreto: pasar un nombre de 300 bytes compuesto solo de ‘A’s devolvía 0 como éxito, con `res` establecido a “AAAAAAAA” (ocho ‘A’s más tres espacios de relleno), reportando éxito para un nombre mucho más largo que NAME_MAX. Este escenario no solo era confuso, sino que podía desencadenar comportamientos erráticos en el kernel.

Cuando un usuario llamaba a `open()` con un componente de ruta más largo que 255 bytes, el sistema VFS solo aplicaba PATH_MAX, no la longitud de un componente individual, por lo que el dentry conservaba el nombre largo original pero se le asignaba un inodo y se volvía positivo. Esto desencadenaba una advertencia en `vfs_open()` que se propagaba hasta `fsnotify_open()` y `fanotify_info_copy_name()`, donde se activaba `WARN_ON_ONCE()`, causando que el evento se informara al espacio de usuario con un nombre vacío.

El impacto no se limitaba solo a una molesta advertencia, sino que podría afectar a los sistemas que dependen de fanotify para monitorear eventos del sistema de archivos. Un nombre vacío en el evento podía romper la lógica de las aplicaciones que dependen de esa información, generando vulnerabilidades potenciales o fallos en la supervisión de seguridad.

Afortunadamente, el sistema de archivos vfat no se veía afectado por este problema, porque su creación pasaba por `xlate_to_uni()`, que rechaza nombres más largos que FAT_LFN_LEN, un límite de 255 caracteres.

La corrección propuesta por Huawei

La solución implementada agrega una comprobación de ‘len > NAME_MAX’ en la entrada de `msdos_format_name()`, que es el único punto de entrada para todo el manejo de nombres msdos en el controlador. Esta verificación se alinea con la que realizan xfs, 9p, ceph y `simple_lookup()` en la búsqueda, asegurando que ningún nombre supere el límite establecido por el sistema.

Este enfoque garantiza que, a partir del kernel Linux 7.3, cualquier intento de utilizar un nombre de archivo más largo que 255 bytes en sistemas FAT será rechazado de forma controlada, en lugar de truncarse silenciosamente. La corrección también evita que se activen advertencias innecesarias en el kernel, mejorando la estabilidad y la seguridad del sistema.

El parche fue enviado y ahora está fusionado para Linux 7.3, y se espera que también se retroporte a los kernels estables en un futuro cercano, para que los usuarios de distribuciones que mantienen versiones antiguas del kernel puedan beneficiarse de esta corrección.

Este tipo de fallos, aunque poco frecuentes en un controlador tan antiguo como FAT, subrayan la importancia de mantener los sistemas actualizados y de revisar el código que maneja operaciones críticas como el acceso a archivos.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados