Investigación de vulnerabilidades en ELM FatFs

Este repositorio documenta seis vulnerabilidades de seguridad confirmadas en FatFs junto con un banco de pruebas, un fuzzer y un generador independiente de imágenes de disco para exploits.

El código fuente original de FatFs se puede encontrar en el directorio FatFs-R0.16.

Este proyecto es un regreso a una evaluación de seguridad de 2017, cuando una auditoría manual y un esfuerzo de fuzzing de varios días identificaron algunos errores básicos, pero poco interesantes, en el driver de FatFs. Nueve años después, en marzo de 2026, retomamos este proyecto utilizando Visual Studio Code, GitHub Copilot en modo "auto" y algunas indicaciones básicas, sin bucles, harnesses ni skills específicos. Los resultados fueron sorprendentes: los errores que pasaron desapercibidos durante la auditoría manual resultaron triviales de encontrar, al usar el LLM para construir automáticamente un fuzzer con entradas novedosas. Este esfuerzo no solo encontró errores interesantes, sino que también automatizó el proceso de validar la explotabilidad en diferentes escenarios de desarrollo embebido.

Consulte los siguientes archivos para obtener notas detalladas:

• 00_INITIAL.md: Investigación y hallazgos iniciales
• 01_PROJECTS.md: Enumeración de proyectos y estudio de versiones de FatFs
• 02_CRITICAL.md: Análisis de los proyectos de mayor impacto

¿Qué es FatFs?

FatFs es una biblioteca de sistema de archivos FAT/exFAT portátil y libre de regalías escrita en C por ChaN (elm-chan.org). Está diseñada para sistemas embebidos con recursos limitados, sin dependencia de SO y normalmente se compila directamente en el firmware. Soporta FAT12, FAT16, FAT32 y exFAT, así como soporte opcional de LFN (Long File Name / nombres de archivo largos) y particiones GPT.

Debido a que FatFs es pequeño, autónomo y tiene una licencia permisiva, se ha convertido en la implementación FAT de facto para firmware de microcontroladores. La biblioteca se integra literalmente en SDK oficiales, RTOS, bootloaders y marcos de aplicación, lo que significa que una única vulnerabilidad upstream se propaga a todos los proyectos downstream que copiaron ff.c.

Proyectos principales

Se ha confirmado que los siguientes proyectos incluyen una versión vulnerable de FatFs. Consulte 02_CRITICAL.md para ver el análisis completo, las rutas de propagación por proyecto y la información de contacto de seguridad.

Resumen de CVE

Valor para el atacante

FatFs no tiene historial de CVE, ni lista de correo de seguridad, ni mecanismo de notificación de parches. Cada proyecto downstream que distribuye ff.c debe descubrir, clasificar y parchear estas vulnerabilidades de forma independiente, normalmente sin saber que está afectado. Eso significa que la ventana entre la divulgación pública y la remediación generalizada se medirá en años, no en días. Por lo tanto, la superficie de ataque práctica no es una aplicación o servicio de software, sino decenas de millones de dispositivos repartidos en docenas de bases de código independientes, muchos de los cuales nunca recibirán un parche.

El escenario de explotación arquetípico es la tarjeta SD maliciosa: un atacante con unos segundos de acceso físico intercambia el medio de almacenamiento en un dispositivo, desde cámaras de consumo hasta drones, impresoras 3D y otros miles de familias de productos. Cada vulnerabilidad de este conjunto es activable montando una imagen FAT manipulada, lo que casi siempre ocurre automáticamente al insertarla, sin requerir interacción del usuario. Dicho esto, el acceso físico no es el único camino.

Los dispositivos que ingieren paquetes de actualización con formato FAT desde una fuente de red, como los marcos de actualización OTA y las actualizaciones de bootloader por arrastrar y soltar, son explotables por cualquier atacante que pueda entregar una imagen maliciosa a la canalización de actualización. Compromisos de la cadena de suministro, una inyección AitM en una fuente de actualización HTTP en claro, o una imagen maliciosa publicada en un portal de distribución de firmware para aficionados. La vía OTA es totalmente remota en cualquier dispositivo que carezca de verificación de integridad autenticada de extremo a extremo de su contenedor de actualización antes de montarlo con FatFs.

Valor para el atacante por CVE

CVE-2026-6682 - Desbordamiento de entero que conduce a una longitud de lectura controlada por el atacante

Al manipular un volumen FAT32 con un campo específico configurado para desbordarse, un atacante puede hacer que un dispositivo víctima lea una cantidad de bytes elegida por el atacante, con el contenido elegido por el atacante, en un búfer fijo: un camino directo a la ejecución de código. En objetivos embebidos bare-metal, el exploit es determinista y no requiere heap spray, fuerza bruta ni una fuga de información como requisito previo.

El atacante necesita controlar el volumen FAT que el objetivo montará. Para la mayoría de los dispositivos, eso significa acceso físico para intercambiar una tarjeta SD. Los dispositivos que aceptan actualizaciones de firmware a través de la red, o que confían en la integridad de un paquete de actualización solo después de que FatFs ya lo ha analizado, son explotables de forma remota.

CVE-2026-6683 - División por cero en la sincronización exFAT

Un atacante que pueda entregar un volumen exFAT manipulado a un dispositivo que ejecute FatFs anterior a R0.16 puede garantizar un fallo en cualquier escritura posterior. FatFs R0.16 añadió una protección parcial en tiempo de montaje que puede rechazar el volumen manipulado antes de que se produzca una escritura, pero el defecto aritmético subyacente no está completamente corregido. En dispositivos que aplican actualizaciones de firmware OTA escribiendo en un medio con formato FAT, una activación exitosa se convierte en un brick remoto de un solo disparo: el proceso de actualización falla a mitad de la escritura y el dispositivo puede ser irrecuperable sin acceso físico a un depurador de hardware.

El atacante necesita que el objetivo monte un volumen exFAT que controle y luego realice cualquier operación de escritura o sincronización. El escenario de la tarjeta SD maliciosa cubre la mayoría de los dispositivos embebidos; para la explotación remota, la canalización OTA del objetivo debe aceptar y montar una imagen proporcionada por el atacante sin verificar primero su integridad.

CVE-2026-6684 - Bucle infinito en el escaneo de particiones GPT

Entregar una imagen de disco GPT con un único campo establecido a su valor máximo hace que el objetivo entre en un bucle leyendo sectores del disco hasta que se retira la alimentación. Contra bootloaders y firmware bare-metal que se ejecutan sin watchdog, esto es un brick permanente: el dispositivo nunca vuelve a completar el arranque. Esta vulnerabilidad está corregida en FatFs R0.16, por lo que solo afecta a dispositivos que distribuyen una versión anterior.

El atacante necesita que el objetivo monte un disco con formato GPT que controle, y el objetivo debe ejecutar una compilación de FatFs anterior a R0.16 con soporte LBA de 64 bits habilitado. Tenga en cuenta que los bootloaders son los objetivos más atractivos aquí precisamente porque tienden a no tener watchdog ni ruta de recuperación.

CVE-2026-6686 - Datos obsoletos de clúster legibles después de un seek más allá del EOF

Cuando un archivo se extiende mediante un seek más allá de su final, FatFs no pone a cero el almacenamiento recién asignado. Cualquier dato escrito previamente en esos sectores por un archivo eliminado puede ser leído por el siguiente proceso que abra el archivo extendido. En dispositivos que rotan imágenes de firmware en un área de almacenamiento OTA, o que comparten una tarjeta SD entre un bootloader y una aplicación, esto puede exponer blobs de firmware anteriores, claves u otro contenido sensible a un lector con menos privilegios.

El atacante necesita acceso de lectura a un archivo en el volumen FAT del objetivo que se haya extendido mediante una operación de seek. Este es principalmente un escenario de acceso local o físico.

CVE-2026-6687 - Desbordamiento de pila a través de la etiqueta de volumen exFAT

Proporcionar un volumen exFAT con una etiqueta de tamaño excesivo hace que FatFs desborde el búfer de etiqueta de la persona que llama cuando la aplicación invoca f_getlabel(). El generador de código STM32CubeMX de ST emite el tamaño de búfer vulnerable en todos los proyectos habilitados para FatFs que produce, lo que significa que esta vulnerabilidad existe en una población enorme y en gran parte no catalogada de firmware STM32 comercial. En dispositivos Cortex-M bare-metal sin cookies de pila ni ASLR (el caso común), esto es una primitiva de ejecución de código de un solo disparo.

El atacante necesita que el objetivo monte un volumen exFAT que controle y luego llame a f_getlabel(). La biblioteca FatFs no lo llama internamente; la aplicación debe llamarlo explícitamente. La mayoría de los proyectos lo hacen como parte de su propia inicialización en el montaje, por lo que en la práctica no se requiere más interacción del atacante en esos proyectos.

CVE-2026-6688 - Desbordamiento de búfer mediante un nombre de archivo LFN largo en el listado de directorios

Al colocar un archivo con un nombre largo en un directorio FAT, un atacante puede desbordar el búfer que la aplicación llamante usa para almacenar ese nombre al recorrer el directorio. El desbordamiento es proporcional a la longitud del nombre de archivo, hasta 255 bytes. Esta vulnerabilidad está en el código llamante, no en FatFs en sí, por lo que el impacto varía según el objetivo, pero cualquier aplicación que recorra un directorio y copie nombres de archivo en un búfer de tamaño fijo sin comprobar la longitud se ve afectada.

El atacante necesita que el objetivo recorra un directorio en un volumen FAT que controle. No se requiere exFAT; funciona con FAT12, FAT16 y FAT32. El soporte de nombres de archivo largos debe estar habilitado en la configuración de FatFs, que es el ajuste predeterminado y recomendado en todas las distribuciones principales.

Detalles de las vulnerabilidades

Se identificaron seis errores distintos en FatFs R0.16 y versiones anteriores.

CVE-2026-6682 - Desbordamiento de entero FAT32 en mount_volume() → finfo.fsize controlado por el atacante

Ubicación: ff.c mount_volume() - fasize *= fs->n_fats

Se produce un desbordamiento de multiplicación DWORD cuando BPB_FATSz32 se manipula para producir un valor grande. Con BPB_FATSz32 = 0x80000001 y NumFATs = 2:```c fasize = 0x80000001; fasize *= 2; // DWORD overflow → 0x00000002

El `fasize` truncado hace que `fs->database` (el inicio del área de datos) 
caiga dentro de la región FAT. Un atacante que controle la imagen de disco puede colocar
una entrada de directorio falsa en el sector superpuesto, provocando que `f_stat()` devuelva
un `finfo.fsize` controlado por el atacante. Cualquier aplicación que luego llame
a `f_read(fp, buf, finfo.fsize, &br)` sin acotar el recuento contra
`sizeof(buf)` desborda el búfer de destino con bytes totalmente controlados por el atacante
- una ruta directa a RCE.

**Impacto en el peor caso:** Ejecución remota de código (desbordamiento de montón o pila) en cualquier
dispositivo embebido que lea un tamaño de archivo de FatFs y lo use como longitud de lectura.

---

### CVE-2026-6683 - División por cero en `sync_fs()` (exFAT)

**Ubicación:** `ff.c` `sync_fs()` - `(n_fatent - 2 - free_clst) * 100 / (n_fatent - 2)`

Cuando `BPB_NumClusEx = 0`, `n_fatent = 2`, lo que hace que el divisor `(n_fatent - 2) = 0`.
Esto se alcanza en cualquier operación de escritura o sincronización sobre un volumen exFAT manipulado,
produciendo un SIGFPE / hard-fault y bloqueando el objetivo.

FatFs R0.16 protege parcialmente contra esto en el momento del montaje (la validación
de clústeres de mapa de bits falla cuando `NumClusEx = 0`). Las versiones anteriores — R0.14b (ArduPilot,
Mbed OS), R0.15 (RIOT OS, STM32), R0.13c (MicroPython) — no tienen dicha protección
y se bloquean incondicionalmente.

**Impacto en el peor caso:** Denegación de servicio / bloqueo del sistema en cualquier escritura a un
volumen exFAT manipulado. Durante una actualización OTA esto puede dejar el dispositivo inutilizable.

---

### CVE-2026-6684 - Bucle de escaneo de particiones GPT sin límite en `find_volume()` (pre-R0.16)

**Ubicación:** `ff.c` `find_volume()` - `for (i = 0; i < n_ent; i++) disk_read()`

Cuando `FF_LBA64 = 1`, `find_volume()` itera sobre cada entrada de partición GPT
para buscar una partición FAT. En las compilaciones pre-R0.16, el contador del bucle se toma
directamente del campo `GPTH_PtNum` del disco (0–0xFFFFFFFF) sin límite
superior. Una imagen GPT manipulada con `GPTH_PtNum = 0xFFFFFFFF` provoca aproximadamente
mil millones de lecturas de disco antes de que la función devuelva "not found", bloqueando el
sistema permanentemente.

R0.16 introdujo `test_gpt_header()`, que valida el CRC32 y aplica
`PtNum ≤ 128` antes de entrar en el bucle.

**Impacto en el peor caso:** Denegación de servicio permanente en el momento del montaje. En dispositivos
sin watchdog (bootloaders, bootrom FPGA de metal desnudo) esto deja el sistema
permanentemente inutilizable.

### CVE-2026-6686 - Datos de clúster no inicializados mediante `f_lseek()` más allá del EOF

**Ubicación:** `ff.c` `f_lseek()`:```c
if (!FF_FS_READONLY && fp->fptr > fp->obj.objsize) {
    fp->obj.objsize = fp->fptr;   // extend, but never zero-fill
    fp->flag |= FA_MODIFIED;
}

Buscar más allá del EOF llama a create_chain() para asignar nuevos clústeres pero nunca pone a cero sus sectores. Cualquier lectura posterior de la región extendida devuelve datos obsoletos en bruto - contenido de archivos previamente eliminados que permanece en el clúster reciclado.

Impacto en el peor de los casos: Divulgación de información del contenido de archivos eliminados (imágenes de firmware antiguas, claves privadas, datos de sensores) a un lector con menos privilegios o a través de una interfaz conectada.

CVE-2026-6687 - Desbordamiento de búfer de pila en f_getlabel() mediante exFAT XDIR_NumLabel

Ubicación: ff.c f_getlabel():```c for (si = di = hs = 0; si < dj.dir[XDIR_NumLabel]; si++) { wc = ld_16(dj.dir + XDIR_Label + si * 2); nw = put_utf((DWORD)hs << 16 | wc, &label[di], 4); di += nw; }

La especificación de exFAT limita `XDIR_NumLabel` a 11 caracteres.  FatFs lo lee
como un `BYTE` sin procesar (0–255) sin validación.  Un volumen manipulado con
`XDIR_NumLabel = 128` provoca que `f_getlabel` escriba 128 caracteres en el
búfer del llamador - normalmente `char label[12]` o `char label[24]` generados por
STM32CubeMX - desbordando la pila hasta en 244 bytes.

**Impacto en el peor caso:** Desbordamiento de búfer de pila en cualquier llamador de `f_getlabel()` en
un volumen exFAT.  El patrón vulnerable canónico (`char label[12]`) aparece
en todos los proyectos generados por STM32CubeMX, AN3224 y UM1721.

---

### CVE-2026-6688 - Desbordamiento de pila/montón del llamador mediante un nombre de archivo LFN largo

**Causa raíz:** Con `FF_USE_LFN` habilitado, `f_readdir()` llena `fno.fname` con
el nombre de archivo largo completo - hasta `FF_LFN_BUF` (255) caracteres.  Los llamadores
escritos para operación solo SFN utilizan búferes de ruta o nombre de tamaño fijo (p. ej.,
`char path[16]`, `char name[14]`) y copian `fno.fname` sin comprobación de
límites.

Patrones vulnerables comunes encontrados en múltiples proyectos:```c
strcpy(entry->name, fno.fname);          // Zephyr: entry->name[14]
sprintf(path, "0:/%s", fno.fname);       // NodeMCU, ChibiOS demo, StarryPilot
sprintf(&cur_path[n], "/%s", fn);        // Samsung TizenRT

Impacto en el peor de los casos: Desbordamiento de pila o montón proporcional a la longitud del LFN (hasta 255 bytes) en cualquier recorrido de directorio sobre un volumen FAT manipulado. Una tarjeta SD manipulada que desborde entry->name[14] en 241 bytes corrompe de forma fiable el marco de pila del programador de Zephyr.

Estructura del Repositorio```

├── harness/ Security test harness and exploit tools │ ├── Makefile Build system (see targets below) │ ├── test_ffconf.h FatFs config for the harness (LFN+exFAT+LBA64) │ ├── diskio_ramdisk.c/h In-memory block device (2 MiB RAM disk) │ ├── ffunicode_stub.c Minimal Unicode stub (CP437 pass-through) │ ├── test_harness.c Deterministic per-bug test suite (CVE-2026-6682 through CVE-2026-6688) │ ├── rce_demo.c Standalone CVE-2026-6682 RCE demo: OTA struct-pointer overwrite │ ├── libfuzzer_harness.c libFuzzer / AFL++ entry point │ ├── exploit_disks.c Standalone disk-image generator (see below) │ ├── build/ Compiled binaries │ └── img/ Generated exploit disk images (*.img) │ ├── fuzzer/ Go corpus generator and structural fuzzer │ ├── main.go Corpus builder + Go native fuzz targets │ ├── fat_image.go FAT12/16/32/exFAT/GPT image construction helpers │ └── corpus/ Seed corpus written by make corpus

---

## Objetivos de compilación del harness

Todos los objetivos se ejecutan desde el directorio `harness/`. Requiere `clang` (o establece `CC=gcc`).

Para compilar el objetivo `afl` en macOS, usa `brew install afl++` y luego `sudo afl-system-config` para preparar tu sistema.

| Objetivo | Descripción |
|--------|-------------|
| `make` / `make test` | Compila y ejecuta la suite de pruebas deterministas con ASan + UBSan |
| `make rce_demo` | Compila y ejecuta la demo de RCE de CVE-2026-6682 (sin sanitizadores, sin stack-protector) |
| `make exploit_disks` | Compila y genera las 14 imágenes de disco de exploit en `harness/img/` |
| `make fuzz_asan` | Compila el binario de libFuzzer (`build/fuzz_fatfs`) |
| `make afl` | Compila el objetivo de AFL++ (requiere `afl-clang-fast` en `PATH`) |
| `make corpus` | Genera el corpus semilla con el generador de Go en `harness/corpus/` |
| `make clean` | Elimina `build/` y `img/` |

### Inicio rápido```sh
# Run the full deterministic test suite
cd harness && make

# Run the CVE-2026-6682 RCE demo
make rce_demo

# Generate all exploit disk images
make exploit_disks

# Fuzz with libFuzzer (requires clang)
make fuzz_asan
build/fuzz_fatfs -max_len=2097152 corpus/

# Fuzz with AFL++
make corpus afl
afl-fuzz -i corpus/ -o findings/ -- build/afl_fatfs @@

Imágenes de Disco de Exploit

make exploit_disks produce 14 imágenes de disco sin procesar en harness/img/, una por combinación de proyecto/vulnerabilidad. Cada imagen se autocomprueba en el momento de la generación montándola con el FatFs incluido. Las imágenes se pueden escribir en una tarjeta SD física:```sh dd if=harness/img/exploit_bug1_espidf.img of=/dev/sdX bs=512

| Image | Bug | Target project(s) | Effect |
|-------|-----|------------------|--------|
| `exploit_bug1_fat32.img` | CVE-2026-6682 | Generic | Entrega una carga útil del tamaño de un puntero mediante `f_read` |
| `exploit_bug1_espidf.img` | CVE-2026-6682 | espressif/esp-idf | `finfo.fsize=16 MB` → desbordamiento de montón en `malloc`/`fread` |
| `exploit_bug1_stm32.img` | CVE-2026-6682 | STMicro stm32-mw-fatfs | `finfo.fsize=1 MB` → desbordamiento del búfer de firmware de 1 KB |
| `exploit_bug1_keystone3.img` | CVE-2026-6682 | KeystoneHQ wallet | `finfo.fsize=512 KB` → desbordamiento del búfer OTA |
| `exploit_bug1_ardupilot.img` | CVE-2026-6682 | ArduPilot / Mbed OS / RIOT / MicroPython | `finfo.fsize=2 MB` → desbordamiento del búfer de lectura de registro |
| `exploit_bug2_exfat.img` | CVE-2026-6683 | ArduPilot / Mbed OS / MicroPython / RIOT | `BPB_NumClusEx=0` → división por cero en `sync_fs` (SIGFPE en versiones anteriores a R0.16) |
| `exploit_bug3_gpt.img` | CVE-2026-6684 | vivado-risc-v / tinyuf2 / circle | `GPTH_PtNum=0xFFFFFFFF` → bucle infinito al arrancar (anterior a R0.16) |
| `exploit_bug5_stale.img` | CVE-2026-6686 | RT-Thread / tinyuf2 / ArduPilot / RIOT | La extensión `f_lseek` expone datos de clústeres eliminados con semilla `0xAA` |
| `exploit_bug6_stm32.img` | CVE-2026-6687 | STMicro stm32-mw-fatfs | `XDIR_NumLabel=128` → desbordamiento de 117 bytes de `label[12]` de CubeMX |
| `exploit_bug6_zephyr.img` | CVE-2026-6687 | Zephyr / ArduPilot / RIOT / MicroPython | `XDIR_NumLabel=255` → desbordamiento de 216 bytes de `label[24]` |
| `exploit_bug7_max255.img` | CVE-2026-6688 | NodeMCU / ChibiOS / StarryPilot / TizenRT | Un LFN de 255 caracteres desborda cualquier búfer fijo < 255 bytes |
| `exploit_bug7_zephyr.img` | CVE-2026-6688 | Zephyr | LFN de 14 caracteres → desbordamiento de 1 byte NUL de `entry->name[14]` |
| `exploit_bug7_grblhal.img` | CVE-2026-6688 | grblHAL | Off-by-one: la comprobación examina la entrada anterior; un LFN de 11 caracteres desborda `dirent.name[12]` en 1 byte NUL |

---

## Suite de pruebas determinista (`test_harness.c`)

El banco de pruebas ejercita seis vulnerabilidades con imágenes de disco creadas manualmente
en memoria y, a continuación, confirma que se alcanzó la ruta de código vulnerable:

- **CVE-2026-6682** - construye una imagen FAT32 `BPB_FATSz32=0x80000001`, la monta y
  confirma que `fs.database` queda dentro de la región FAT; luego ejecuta la cadena
  RCE completa (entrada de directorio falsa → `f_read` del puntero de función plantado →
  `rce_proof_of_execution()` se ejecuta).
- **CVE-2026-6683** - documenta el divisor `(n_fatent-2)` y confirma la ruta
  aritmética; comprueba que R0.16 rechaza la imagen en el momento del montaje.
- **CVE-2026-6684** - construye una imagen GPT `GPTH_PtNum=0xFFFFFFFF` y confirma que
  R0.16 la rechaza en ≤ 3 lecturas de disco mediante `test_gpt_header()`.
- **CVE-2026-6686** - presemilla todos los clústeres de datos con `0xAA`, escribe un archivo corto,
  lo extiende mediante `f_lseek` y lo vuelve a leer para confirmar que los bytes obsoletos son visibles.
- **CVE-2026-6687** - construye una imagen exFAT con `XDIR_NumLabel=128`, llama a
  `f_getlabel` con un búfer de prueba y cuenta el desbordamiento más allá del byte 24.
- **CVE-2026-6688** - construye un directorio FAT16 con un LFN de 50 caracteres, lo lee mediante
  `f_readdir` y confirma que la longitud de `fno.fname` supera los búferes típicos del llamador.

---

## Demo de RCE para CVE-2026-6682 (`rce_demo.c`)

Una demostración autocontenida y realista de la cadena de explotación de CVE-2026-6682,
modelada a partir de código de actualización de firmware OTA embebido. Se declara una estructura con un
búfer de cabecera de tamaño fijo seguido inmediatamente por un callback de puntero a función:```c
typedef struct {
    uint8_t  fw_header[128];   // buffer the developer reads into
    uint32_t crc32;
    uint32_t version;
    void   (*on_apply)(void);  // callback - attacker target
} ota_ctx_t;

El demo construye una imagen de disco manipulada donde DIR_FileSize = sizeof(ota_ctx_t), coloca la dirección de rce_win() en el desplazamiento de byte correcto en el sector de payload, y luego ejecuta el comprobador OTA. f_read escribe más allá de fw_header en on_apply, y la posterior llamada a ctx.on_apply() invoca rce_win(), estableciendo rce_canary = 0xDEAD.

Compila y ejecuta: cd harness && make rce_demo

Fuzzer (fuzzer/)

El fuzzer de Go tiene dos modos:

1. Generador de corpus (go run . -out ./corpus o make corpus): escribe 18 imágenes semilla estructuradas que cubren seis clases de errores, las tres variantes de FAT, GPT normal y malformado, y 50 mutaciones aleatorias de un solo byte de una imagen FAT32 válida.

2. Fuzzer nativo de Go (go test -fuzz=FuzzFAT32BPB): fuzzing estructural de los valores de los campos BPB con el fuzzer integrado de Go; valida que las relaciones entre campos se mantienen sin llamar a C.

El corpus semilla alimenta tanto el binario de libFuzzer (build/fuzz_fatfs) como el objetivo de AFL++ (build/afl_fatfs).

ESP-IDF vía QEMU

Este repositorio incluye un caso de prueba Docker autocontenido que demuestra un patrón de desbordamiento del llamador (caller overflow) relevante para ESP32 mediante el recorrido de directorios de FatFs en firmware ESP-IDF dentro del emulador ESP32 QEMU de Espressif.

La imagen PoC actual es intencionadamente híbrida:

• Mantiene la geometría FAT32 manipulada al estilo CVE-2026-6682 para que el directorio raíz forjado esté controlado de forma fiable.
• Incorpora un nombre de archivo VFAT largo que devuelve readdir().
• La aplicación luego replica patrones públicos de código ESP32 (strcpy / strcat para el ensamblaje de rutas) y copia el nombre de archivo largo en un búfer fijo de 32 bytes.

Esa copia final es la condición al estilo CVE-2026-6688: desbordamiento en el lado del llamador mediante el uso sin límites de nombres de archivo largos.``` cd esp32-qemu-test ./run.sh

O alternativamente:```
docker build -t fatfs-esp32-vuln-test esp32-qemu-test/
docker run --rm fatfs-esp32-vuln-test

Por qué esto corresponde a CVE-2026-6688

f_readdir() puede devolver nombres largos (LFN) de hasta 255 caracteres. Muchos llamadores embebidos reales todavía copian nombres en búferes fijos más pequeños. Los ejemplos públicos de ESP32 incluyen patrones equivalentes a:``` strcpy(fn, entry->d_name); strcat(path, "/"); strcat(path, entry->d_name);

Con una imagen FAT diseñada que contiene un nombre de archivo largo, estas copias desbordan el
búfer del llamador.

### Cadena de PoC en este repositorio

| Paso | Descripción | Marcador |
|------|-------------|--------|
| 1 | Una imagen de almacenamiento diseñada se monta y devuelve entradas de directorio controladas por el atacante | (montaje exitoso) |
| 2 | El nombre de archivo largo se copia en `char name[32]` mediante la ruta de copia insegura de patrón público | `[VULN-BUG7-CONFIRMED]` |
| 3 | La corrupción de la guarda se registra, seguida de un fallo de datos de control en QEMU | `guard=0x61616161`, `Guru Meditation Error` |

El PoC aún conserva una ruta heredada de sobrescritura de callback OTA estilo CVE-2026-6682
para contexto y salida de marcador (`PWNED-UART`), pero la prueba específica de este error aquí
es el marcador de desbordamiento del búfer del llamador por nombre de archivo largo indicado anteriormente.

Salida representativa:```
I (...) fatfs_vuln: PoC: CVE-2026-6688 long-LFN caller overflow probe (ESP32 public-pattern copy path)
...
PWNED-UART
E (...) fatfs_vuln: [VULN-BUG7-CONFIRMED] guard corrupted after filename copy
E (...) fatfs_vuln: entry='esp32_lfn_trigger_aaaa...aaaa.bin' len=78 guard=0x61616161
Guru Meditation Error: Core  0 panic'ed (...)

Nota sobre la numeración de CVE

Un comportamiento de resta sin signo fue previamente señalado y reportado durante esta investigación, y luego eliminado del corpus de CVE. Debido a esto, notarás una brecha en la numeración porque omitimos intencionalmente ese registro retirado del conjunto de CVE activos de este repositorio. El Programa CVE puede ser un poco estricto en cuanto a referencias a registros no publicados, por lo que esto evita problemas de enlaces cruzados mientras se mantiene la historia precisa. Para los más curiosos, puedes inspeccionar el historial de git de este repositorio para obtener los detalles de ese hallazgo.

Gracias a David Brown por llamar nuestra atención sobre el informe en disputa. Para conocer el estado upstream y la guía de parches, sigue la página oficial de parches de FatFs de ChaN: https://elm-chan.org/fsw/ff/patches.html