Pesquisa de Vulnerabilidades no ELM FatFs

Este repositório documenta seis vulnerabilidades de segurança confirmadas no FatFs, juntamente com um harness de teste, um fuzzer e um gerador autônomo de imagens de disco de exploit.

O código-fonte original do FatFs pode ser encontrado no diretório FatFs-R0.16.

Este projeto é um retorno a uma avaliação de segurança de 2017, quando uma auditoria manual e um esforço de fuzzing de vários dias identificaram alguns bugs básicos, mas não interessantes, no driver FatFs. Nove anos depois, em março de 2026, revisitamos este projeto usando Visual Studio Code, GitHub Copilot no modo "auto" e alguns prompts básicos, sem loops, harnesses ou skills específicos. Os resultados foram surpreendentes - bugs que foram ignorados durante a auditoria manual tornaram-se triviais de encontrar, ao usar o LLM para construir automaticamente um fuzzer com entradas inéditas. Esse esforço não apenas encontrou bugs interessantes, como também automatizou o processo de validação da explorabilidade em diferentes cenários de desenvolvimento embarcado.

Consulte os seguintes arquivos para notas detalhadas:

• 00_INITIAL.md: Investigação e descobertas iniciais
• 01_PROJECTS.md: Enumeração de projetos e levantamento de versões do FatFs
• 02_CRITICAL.md: Análise dos projetos de maior impacto

O que é o FatFs?

O FatFs é uma biblioteca de sistema de arquivos FAT/exFAT portável e livre de royalties, escrita em C por ChaN (elm-chan.org). É projetada para sistemas embarcados com recursos limitados, sem dependência de SO, e é tipicamente compilada diretamente no firmware. Ela suporta FAT12, FAT16, FAT32 e exFAT, bem como suporte opcional a LFN (Long File Name) e partições GPT.

Por ser pequeno, autocontido e com licença permissiva, o FatFs tornou-se o padrão de facto para implementação FAT em firmware de microcontroladores. A biblioteca é incorporada verbatim em SDKs oficiais, RTOSes, bootloaders e frameworks de aplicação — ou seja, uma única vulnerabilidade upstream se propaga para todos os projetos downstream que copiaram ff.c.

Projetos Principais

Os seguintes projetos foram confirmados como incluindo uma versão vulnerável do FatFs. Consulte 02_CRITICAL.md para a análise completa, os caminhos de propagação por projeto e as informações de contato de segurança.

Resumo das CVEs

Valor para o Atacante

O FatFs não tem histórico de CVEs, lista de discussão de segurança ou mecanismo de notificação de patches. Cada projeto downstream que incorpora ff.c precisa descobrir, triar e corrigir essas vulnerabilidades de forma independente, geralmente sem saber que é afetado. Isso significa que a janela entre a divulgação pública e a remediação em larga escala será medida em anos, não em dias. A superfície de ataque prática, portanto, não é um único aplicativo ou serviço, mas dezenas de milhões de dispositivos em dezenas de codebases independentes, muitos dos quais nunca receberão um patch.

O cenário de exploração arquetípico é o cartão SD maligno: um atacante com alguns segundos de acesso físico troca o meio de armazenamento em um dispositivo, de câmeras de consumo a drones, de impressoras 3D a mil outras famílias de produtos. Todas as vulnerabilidades deste conjunto são acionáveis ao montar uma imagem FAT adulterada, o que quase sempre acontece automaticamente na inserção, sem exigir interação do usuário. Dito isso, o acesso físico não é o único caminho.

Dispositivos que recebem pacotes de atualização formatados em FAT de uma fonte de rede, como frameworks de atualização OTA e atualizações de bootloader por arrastar e soltar, são exploráveis por qualquer atacante que consiga entregar uma imagem maliciosa ao pipeline de atualização. Comprometimento da cadeia de suprimentos, uma injeção AitM (adversary-in-the-middle) em um feed de atualização HTTP em texto claro ou uma imagem maliciosa publicada em um portal de distribuição de firmware amador. O caminho OTA é totalmente remoto em qualquer dispositivo que não tenha verificação autenticada de integridade de ponta a ponta de seu contêiner de atualização antes de montá-lo com o FatFs.

Valor para o Atacante por CVE

CVE-2026-6682 - Estouro de inteiro levando a um comprimento de leitura controlado pelo atacante

Ao criar um volume FAT32 com um campo específico configurado para estourar, um atacante pode fazer com que um dispositivo vítima leia um número de bytes escolhido pelo atacante para um buffer fixo — um caminho direto para a execução de código. Em alvos embarcados bare-metal, o exploit é determinístico e não exige heap spray, força bruta ou vazamento de informação como pré-requisito.

O atacante precisa de controle sobre o volume FAT que o alvo irá montar. Para a maioria dos dispositivos, isso significa acesso físico para trocar um cartão SD. Dispositivos que aceitam atualizações de firmware pela rede, ou que confiam na integridade de um pacote de atualização apenas depois que o FatFs já o analisou, são exploráveis remotamente.

CVE-2026-6683 - Divisão por zero na sincronização exFAT

Um atacante que consiga entregar um volume exFAT adulterado a um dispositivo executando FatFs anterior à R0.16 pode garantir uma falha (crash) em qualquer gravação subsequente. O FatFs R0.16 adicionou uma proteção parcial no momento da montagem que pode rejeitar o volume adulterado antes que uma gravação ocorra, mas o defeito aritmético subjacente não foi totalmente corrigido. Contra dispositivos que aplicam atualizações de firmware OTA gravando em um meio formatado em FAT, um acionamento bem-sucedido torna-se um brick remoto de tiro único: o processo de atualização falha no meio da gravação e o dispositivo pode ser irrecuperável sem acesso físico a um depurador de hardware.

O atacante precisa que o alvo monte um volume exFAT sob seu controle e depois execute qualquer operação de gravação ou sincronização. O cenário do cartão SD maligno cobre a maioria dos dispositivos embarcados; para exploração remota, o pipeline OTA do alvo deve aceitar e montar uma imagem fornecida pelo atacante sem primeiro verificar sua integridade.

CVE-2026-6684 - Loop infinito na varredura de partição GPT

Entregar uma imagem de disco GPT com um único campo definido com seu valor máximo faz com que o alvo fique em loop lendo setores do disco até que a energia seja removida. Contra bootloaders e firmware bare-metal que executam sem watchdog, isso é um brick permanente: o dispositivo nunca mais conclui a inicialização. Essa vulnerabilidade é corrigida no FatFs R0.16, portanto afeta apenas dispositivos que incorporam uma versão mais antiga.

O atacante precisa que o alvo monte um disco formatado em GPT sob seu controle, e o alvo deve estar executando uma compilação do FatFs anterior à R0.16 com suporte a LBA de 64 bits habilitado. Observe que os bootloaders são os alvos mais atraentes aqui justamente porque tendem a não ter watchdog e nem caminho de recuperação.

CVE-2026-6686 - Dados de cluster obsoletos legíveis após seek além do EOF

Quando um arquivo é estendido ao buscar (seek) além do seu final, o FatFs não zera o armazenamento recém-alocado. Quaisquer dados gravados anteriormente nesses setores por um arquivo excluído podem ser lidos pelo próximo processo que abrir o arquivo estendido. Em dispositivos que alternam entre imagens de firmware em uma área de staging de OTA, ou que compartilham um cartão SD entre um bootloader e um aplicativo, isso pode expor blobs de firmware anteriores, chaves ou outro conteúdo sensível a um leitor com menos privilégios.

O atacante precisa de acesso de leitura a um arquivo no volume FAT do alvo que foi estendido por meio de uma operação de seek. Este é principalmente um cenário local ou de acesso físico.

CVE-2026-6687 - Estouro de pilha via rótulo de volume exFAT

Fornecer um volume exFAT com um rótulo superdimensionado faz com que o FatFs estoure o buffer de rótulo do chamador quando o aplicativo chama f_getlabel(). O gerador de código STM32CubeMX da ST emite o tamanho de buffer vulnerável em todo projeto habilitado para FatFs que produz, o que significa que essa vulnerabilidade existe em uma população enorme e amplamente não catalogada de firmware STM32 comercial. Em dispositivos Cortex-M bare-metal sem stack cookies ou ASLR (o caso comum), isso é uma primitiva de execução de código de tiro único.

O atacante precisa que o alvo monte um volume exFAT sob seu controle e depois chame f_getlabel(). A biblioteca FatFs não chama isso internamente — o aplicativo deve chamá-lo explicitamente. A maioria dos projetos o faz como parte de sua própria inicialização no momento da montagem, não exigindo, na prática, nenhuma interação adicional do atacante nesses projetos.

CVE-2026-6688 - Estouro de buffer via nome de arquivo LFN longo na listagem de diretório

Ao colocar um arquivo com um nome longo em um diretório FAT, um atacante pode estourar o buffer que um aplicativo chamador usa para armazenar esse nome ao iterar pelo diretório. O estouro é proporcional ao comprimento do nome do arquivo, até 255 bytes. Essa vulnerabilidade está no código chamador, não no próprio FatFs, portanto o impacto varia de acordo com o alvo — mas qualquer aplicativo que itere por um diretório e copie nomes de arquivo para um buffer de tamanho fixo sem verificar o comprimento é afetado.

O atacante precisa que o alvo percorra um diretório em um volume FAT sob seu controle. Não é necessário exFAT; isso funciona em FAT12, FAT16 e FAT32. O suporte a nomes longos de arquivo deve estar habilitado na configuração do FatFs, que é a configuração padrão e recomendada em todas as principais distribuições.

Detalhes das Vulnerabilidades

Seis bugs distintos foram identificados no FatFs R0.16 e versões anteriores.

CVE-2026-6682 - Estouro de inteiro FAT32 em mount_volume() → finfo.fsize controlado pelo atacante

Localização: ff.c mount_volume() - fasize *= fs->n_fats

Um estouro de multiplicação DWORD ocorre quando BPB_FATSz32 é manipulado para produzir um valor grande. Com BPB_FATSz32 = 0x80000001 e NumFATs = 2:```c fasize = 0x80000001; fasize *= 2; // DWORD overflow → 0x00000002

O `fasize` truncado faz com que `fs->database` (o início da área de dados) caia dentro da região FAT.  Um atacante que controla a imagem do disco pode colocar uma entrada de diretório falsa no setor sobreposto, fazendo com que `f_stat()` retorne um `finfo.fsize` controlado pelo atacante.  Qualquer aplicação que então chame `f_read(fp, buf, finfo.fsize, &br)` sem limitar a contagem em relação a `sizeof(buf)` faz transbordar o buffer de destino com bytes totalmente controlados pelo atacante - um caminho direto para RCE.

**Impacto no pior caso:** Execução remota de código (estouro de heap ou pilha) em qualquer dispositivo embarcado que leia um tamanho de arquivo do FatFs e o use como tamanho de leitura.

---

### CVE-2026-6683 - Divisão por zero em `sync_fs()` (exFAT)

**Local:** `ff.c` `sync_fs()` - `(n_fatent - 2 - free_clst) * 100 / (n_fatent - 2)`

Quando `BPB_NumClusEx = 0`, `n_fatent = 2`, tornando o divisor `(n_fatent - 2) = 0`. Isso é alcançado em qualquer operação de escrita ou sincronização em um volume exFAT adulterado, produzindo um SIGFPE / hard-fault e travando o alvo.

O FatFs R0.16 protege parcialmente contra isso no momento da montagem (a validação de bitmap-cluster falha quando `NumClusEx = 0`).  Versões mais antigas - R0.14b (ArduPilot, Mbed OS), R0.15 (RIOT OS, STM32), R0.13c (MicroPython) - não possuem essa proteção e travam incondicionalmente.

**Impacto no pior caso:** Negação de serviço / travamento do sistema em qualquer escrita em um volume exFAT adulterado.  Durante uma atualização OTA, isso pode inutilizar o dispositivo.

---

### CVE-2026-6684 - Loop de varredura de partições GPT sem limite em `find_volume()` (pré-R0.16)

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

Quando `FF_LBA64 = 1`, `find_volume()` itera sobre todas as entradas de partição GPT para procurar uma partição FAT.  Em builds pré-R0.16, a contagem do loop é obtida diretamente do campo `GPTH_PtNum` no disco (0–0xFFFFFFFF) sem limite superior.  Uma imagem GPT adulterada com `GPTH_PtNum = 0xFFFFFFFF` causa aproximadamente um bilhão de leituras de disco antes que a função retorne "not found", travando o sistema permanentemente.

O R0.16 introduziu `test_gpt_header()`, que valida o CRC32 e impõe `PtNum ≤ 128` antes de entrar no loop.

**Impacto no pior caso:** Negação de serviço permanente no momento da montagem.  Em dispositivos sem watchdog (bootloaders, bootrom FPGA bare-metal), isso torna o sistema permanentemente inutilizável.

### CVE-2026-6686 - Dados de cluster não inicializados via `f_lseek()` além do EOF

**Local:** `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 além do EOF chama create_chain() para alocar novos clusters, mas nunca zera seus setores. Qualquer leitura subsequente da região estendida retorna dados obsoletos brutos - conteúdo de arquivos excluídos anteriormente que permanecem no cluster reciclado.

Impacto no pior caso: Divulgação de informações do conteúdo de arquivos excluídos (imagens antigas de firmware, chaves privadas, dados de sensores) para um leitor com menos privilégios ou através de uma interface conectada.

CVE-2026-6687 - Estouro de buffer na pilha em f_getlabel() via XDIR_NumLabel do exFAT

Local: 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; }

A especificação exFAT limita `XDIR_NumLabel` a 11 caracteres.  O FatFs lê
isso como um `BYTE` bruto (0–255) sem validação.  Um volume elaborado com
`XDIR_NumLabel = 128` faz com que `f_getlabel` escreva 128 caracteres no
buffer do chamador - normalmente `char label[12]` ou `char label[24]` como
gerado pelo STM32CubeMX - estourando a pilha em até 244 bytes.

**Impacto no pior caso:** Estouro de buffer de pilha em qualquer chamador de
`f_getlabel()` em um volume exFAT.  O padrão vulnerável canônico (`char label[12]`) aparece
em todos os projetos gerados pelo STM32CubeMX, AN3224 e UM1721.

---

### CVE-2026-6688 - Estouro da pilha/heap do chamador via nome de arquivo LFN longo

**Causa raiz:** Com `FF_USE_LFN` ativado, `f_readdir()` preenche `fno.fname` com
o nome completo do Long File Name - até `FF_LFN_BUF` (255)
caracteres.  Chamadores escritos para operação somente com SFN usam buffers de
caminho ou nome de tamanho fixo (ex.: `char path[16]`, `char name[14]`) e
copiam `fno.fname` sem verificação de limites.

Padrões vulneráveis comuns encontrados em vários projetos:```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 no pior caso: Estouro de pilha ou heap proporcional ao comprimento do LFN (até 255 bytes) em qualquer travessia de diretório em um volume FAT adulterado. Um cartão SD adulterado que estoura entry->name[14] em 241 bytes corrompe de forma confiável o quadro de pilha do escalonador do Zephyr.

Estrutura do Repositório```

├── 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

---

## Alvos de compilação do harness

Todos os alvos são executados a partir do diretório `harness/`. Requer `clang` (ou defina `CC=gcc`).

Para compilar o alvo `afl` no macOS, use `brew install afl++` e depois `sudo afl-system-config` para preparar o seu sistema.

| Alvo | Descrição |
|--------|-------------|
| `make` / `make test` | Compila e executa o conjunto de testes determinístico com ASan + UBSan |
| `make rce_demo` | Compila e executa a demo de RCE CVE-2026-6682 (sem sanitizadores, sem stack-protector) |
| `make exploit_disks` | Compila e gera todas as 14 imagens de disco de exploit em `harness/img/` |
| `make fuzz_asan` | Compila o binário do libFuzzer (`build/fuzz_fatfs`) |
| `make afl` | Compila o alvo AFL++ (requer `afl-clang-fast` no `PATH`) |
| `make corpus` | Gera o corpus inicial por meio do gerador Go em `harness/corpus/` |
| `make clean` | Remove `build/` e `img/` |

### Início 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 @@

Imagens de Disco de Exploits

make exploit_disks produz 14 imagens de disco brutas em harness/img/, uma por combinação de projeto/vulnerabilidade. Cada imagem é autotestada no momento da geração, montando-a com o FatFs incluído. As imagens podem ser gravadas em um cartão SD físico:```sh dd if=harness/img/exploit_bug1_espidf.img of=/dev/sdX bs=512

| Imagem | Bug | Projeto(s) alvo | Efeito |
|-------|-----|------------------|--------|
| `exploit_bug1_fat32.img` | CVE-2026-6682 | Genérico | Entrega payload do tamanho de um ponteiro via `f_read` |
| `exploit_bug1_espidf.img` | CVE-2026-6682 | espressif/esp-idf | `finfo.fsize=16 MB` → estouro de heap via `malloc`/`fread` |
| `exploit_bug1_stm32.img` | CVE-2026-6682 | STMicro stm32-mw-fatfs | `finfo.fsize=1 MB` → estouro do buffer de firmware de 1 KB |
| `exploit_bug1_keystone3.img` | CVE-2026-6682 | KeystoneHQ wallet | `finfo.fsize=512 KB` → estouro do buffer de OTA |
| `exploit_bug1_ardupilot.img` | CVE-2026-6682 | ArduPilot / Mbed OS / RIOT / MicroPython | `finfo.fsize=2 MB` → estouro do buffer de leitura de log |
| `exploit_bug2_exfat.img` | CVE-2026-6683 | ArduPilot / Mbed OS / MicroPython / RIOT | `BPB_NumClusEx=0` → divisão por zero em `sync_fs` (SIGFPE em pré-R0.16) |
| `exploit_bug3_gpt.img` | CVE-2026-6684 | vivado-risc-v / tinyuf2 / circle | `GPTH_PtNum=0xFFFFFFFF` → loop infinito na inicialização (pré-R0.16) |
| `exploit_bug5_stale.img` | CVE-2026-6686 | RT-Thread / tinyuf2 / ArduPilot / RIOT | a extensão `f_lseek` expõe dados de clusters excluídos com seed `0xAA` |
| `exploit_bug6_stm32.img` | CVE-2026-6687 | STMicro stm32-mw-fatfs | `XDIR_NumLabel=128` → estouro de 117 bytes de `label[12]` do CubeMX |
| `exploit_bug6_zephyr.img` | CVE-2026-6687 | Zephyr / ArduPilot / RIOT / MicroPython | `XDIR_NumLabel=255` → estouro de 216 bytes de `label[24]` |
| `exploit_bug7_max255.img` | CVE-2026-6688 | NodeMCU / ChibiOS / StarryPilot / TizenRT | LFN de 255 caracteres estoura qualquer buffer fixo < 255 bytes |
| `exploit_bug7_zephyr.img` | CVE-2026-6688 | Zephyr | LFN de 14 caracteres → estouro de 1 byte NUL de `entry->name[14]` |
| `exploit_bug7_grblhal.img` | CVE-2026-6688 | grblHAL | Off-by-one: a proteção verifica a entrada anterior; LFN de 11 caracteres estoura `dirent.name[12]` em 1 byte NUL |

---

## Suíte de Testes Determinística (`test_harness.c`)

O harness de teste exercita seis bugs com imagens de disco artesanais construídas
em memória e, em seguida, confirma que o caminho de código vulnerável foi alcançado:

- **CVE-2026-6682** - constrói uma imagem FAT32 com `BPB_FATSz32=0x80000001`, monta-a e
  confirma que `fs.database` está dentro da região FAT; em seguida, executa a
  cadeia RCE completa (entrada de diretório falsa → `f_read` do ponteiro de função plantado →
  `rce_proof_of_execution()` chamado).
- **CVE-2026-6683** - documenta o divisor `(n_fatent-2)` e confirma o caminho
  aritmético; verifica que R0.16 rejeita a imagem no momento da montagem.
- **CVE-2026-6684** - constrói uma imagem GPT com `GPTH_PtNum=0xFFFFFFFF` e confirma que
  R0.16 a rejeita em ≤ 3 leituras de disco via `test_gpt_header()`.
- **CVE-2026-6686** - pré-preenche todos os clusters de dados com `0xAA`, grava um arquivo curto,
  estende-o via `f_lseek` e lê de volta para confirmar que bytes obsoletos estão visíveis.
- **CVE-2026-6687** - constrói uma imagem exFAT com `XDIR_NumLabel=128`, chama
  `f_getlabel` para um buffer de sonda e conta o estouro além do byte 24.
- **CVE-2026-6688** - constrói um diretório FAT16 com um LFN de 50 caracteres, lê-o via
  `f_readdir` e confirma que o comprimento de `fno.fname` excede os buffers típicos do chamador.

---

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

Uma demonstração realista e autocontida da cadeia de exploração do CVE-2026-6682
modelada a partir de código de atualização de firmware OTA embarcado.  Uma struct é declarada com um
buffer de cabeçalho de tamanho fixo seguido imediatamente por um callback de ponteiro de função:```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;

A demo constrói uma imagem de disco forjada onde DIR_FileSize = sizeof(ota_ctx_t), insere o endereço de rce_win() no deslocamento de byte correto no setor de payload e, em seguida, executa o verificador de OTA. f_read grava além de fw_header em on_apply, e a chamada subsequente a ctx.on_apply() invoca rce_win(), definindo rce_canary = 0xDEAD.

Compilar e executar: cd harness && make rce_demo

Fuzzer (fuzzer/)

O fuzzer Go tem dois modos:

1. Gerador de corpus (go run . -out ./corpus ou make corpus): grava 18 imagens de semente estruturadas cobrindo seis classes de bugs, todas as três variantes de FAT, GPT normal e malformado, e 50 mutações aleatórias de um único byte de uma imagem FAT32 válida.

2. Fuzzer nativo do Go (go test -fuzz=FuzzFAT32BPB): fuzzing estrutural dos valores dos campos do BPB com o fuzzer integrado do Go; valida que as relações entre os campos se mantêm sem chamar código em C.

O corpus de sementes alimenta tanto o binário do libFuzzer (build/fuzz_fatfs) quanto o alvo do AFL++ (build/afl_fatfs).

ESP-IDF via QEMU

Este repositório inclui um caso de teste Docker autocontido que demonstra um padrão de overflow no chamador do CVE-2026-6688, relevante para ESP32, usando travessia de diretórios do FatFs em firmware ESP-IDF dentro do emulador QEMU ESP32 da Espressif.

A imagem de PoC atual é intencionalmente híbrida:

• Ela mantém a geometria FAT32 forjada no estilo do CVE-2026-6682 para que o diretório raiz forjado seja controlado de forma confiável.
• Ela incorpora um nome de arquivo VFAT longo que é retornado por readdir().
• O aplicativo então reproduz padrões públicos de código ESP32 (montagem de caminho com strcpy / strcat) e copia o nome de arquivo longo para um buffer fixo de 32 bytes.

Essa cópia final é a condição no estilo do CVE-2026-6688: overflow no lado do chamador por meio do uso sem limites de nomes de arquivo longos.``` cd esp32-qemu-test ./run.sh

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

Por que isso corresponde à CVE-2026-6688

f_readdir() pode retornar nomes longos (LFN) de até 255 caracteres. Muitos chamadores embarcados reais ainda copiam nomes para buffers fixos menores. Exemplos públicos de ESP32 incluem padrões equivalentes a:``` strcpy(fn, entry->d_name); strcat(path, "/"); strcat(path, entry->d_name);

Com uma imagem FAT especialmente criada contendo um nome de arquivo longo, essas cópias estouram o buffer do chamador.

### Cadeia de PoC neste repositório

| Passo | Descrição | Marcador |
|------|-------------|--------|
| 1 | Uma imagem de armazenamento criada é montada e retorna entradas de diretório controladas pelo atacante | (mount succeeds) |
| 2 | Um nome de arquivo longo é copiado para `char name[32]` via caminho de cópia insegura de padrão público | `[VULN-BUG7-CONFIRMED]` |
| 3 | A corrupção do guard é registrada, seguida por uma falha nos dados de controle no QEMU | `guard=0x61616161`, `Guru Meditation Error` |

O PoC ainda mantém um caminho legado de sobrescrita de callback OTA no estilo CVE-2026-6682 para contexto e saída de marcador (`PWNED-UART`), mas a prova específica da falha aqui é o marcador acima de estouro do chamador por nome de arquivo longo.

Saída 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 a Numeração de CVE

Um comportamento de subtração sem sinal foi anteriormente observado e relatado durante esta pesquisa e, posteriormente, removido do corpus de CVEs. Por causa disso, você notará uma lacuna na numeração, pois omitimos intencionalmente esse registro retirado do conjunto ativo de CVEs deste repositório. O Programa CVE pode ser um pouco exigente quanto a referências a registros não publicados, então isso evita dramas de linkagem cruzada, mantendo o histórico preciso. Para os muito curiosos, você pode inspecionar o histórico do git deste repositório para obter os detalhes dessa descoberta.

Agradecemos a David Brown por chamar nossa atenção para o relatório contestado. Para o status upstream e orientação sobre patches, siga a página oficial de patches FatFs do ChaN página: https://elm-chan.org/fsw/ff/patches.html