FatFs R0.16 corregge GPT ma sette falle espongono device embedded

🛡️ Executive Summary

• runZero documenta sette vulnerabilità in FatFs, attivabili con immagini FAT, exFAT o GPT create per colpire firmware embedded.
• Gli impatti includono corruzione memoria, denial of service, leak di dati e possibili primitive di esecuzione codice nei sistemi privi di protezioni.
• FatFs R0.16 corregge il loop GPT, ma gli integratori devono auditare versioni vendored, wrapper e gestione dei nomi lunghi.

FatFs R0.16 riporta l’attenzione su uno dei componenti più silenziosi ma diffusi dell’ecosistema embedded: il modulo filesystem FAT/exFAT sviluppato da ChaN, usato da firmware, RTOS, bootloader e applicazioni a risorse limitate per leggere e scrivere su SD card, chiavette USB, memorie flash e supporti rimovibili. La nuova release introduce correzioni e miglioramenti, inclusa una validazione più robusta nei percorsi GPT, ma la ricerca pubblicata da runZero mostra che la superficie d’attacco resta ampia. I ricercatori hanno identificato sette vulnerabilità tramite fuzzing assistito da AI, con difetti che coinvolgono mount dei volumi, gestione di exFAT, nomi file lunghi, cache sporca, seek oltre la fine del file e scansione delle partizioni. Il rischio non riguarda soltanto una libreria di nicchia: FatFs è integrato in piattaforme come ESP-IDF, STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT e SWUpdate, con ricadute potenziali su IoT, droni, controller industriali, telecamere, wallet hardware e sistemi di aggiornamento firmware.

FatFs è piccolo ma centrale nella supply chain embedded

FatFs nasce per fornire un modulo filesystem generico, scritto in ANSI C, indipendente dal driver fisico del supporto. Questa architettura spiega la sua diffusione: lo sviluppatore integra la libreria e implementa soltanto lo strato di accesso al disco, adattandolo a microcontrollori, schede embedded, flash esterne o controller personalizzati. Il codice è portabile su architetture molto diverse, dai vecchi 8051 ai moderni ARM, e mantiene un’impronta ridotta in RAM e flash, caratteristica decisiva per dispositivi con vincoli severi. Il supporto a FAT, exFAT, nomi lunghi, partizioni multiple, code page, configurazioni thread-safe e RTOS rende la libreria adatta a prodotti industriali e consumer che devono scambiare dati con sistemi Windows, strumenti di manutenzione o procedure di aggiornamento basate su supporti rimovibili. Proprio questa semplicità operativa crea però un problema di sicurezza: quando una libreria così piccola viene copiata, modificata e vendorizzata in molti firmware, le patch upstream non arrivano automaticamente ai dispositivi finali. Ogni integrazione può aggiungere wrapper, buffer statici, funzioni di logging, parser di aggiornamento e percorsi di mount automatico che trasformano un bug locale in una vulnerabilità di filiera.

R0.16 introduce correzioni ma non chiude l’intero fronte

La release FatFs R0.16, pubblicata nel 2025, rimuove limitazioni storiche su exFAT, corregge problemi di directory e migliora la gestione di alcuni casi limite. Il punto più rilevante nel contesto della ricerca runZero riguarda la protezione contro il loop nella scansione delle partizioni GPT, classificato come CVE-2026-6684 nelle analisi dei ricercatori. Nelle versioni precedenti, un abuso del conteggio delle entry GPT poteva portare a una scansione di mount non terminante, generando un denial of service particolarmente grave nei percorsi di boot o nei dispositivi che montano automaticamente supporti esterni. R0.16 introduce una validazione protettiva che riduce questo scenario, ma non equivale a una soluzione completa per tutte le falle descritte. Alcune vulnerabilità interessano R0.16 e versioni precedenti, altre dipendono dal modo in cui gli integratori downstream copiano nomi, etichette o metadati in buffer locali. Per questo la raccomandazione “aggiornare FatFs” è necessaria ma non sufficiente: serve anche verificare come la libreria viene usata nel firmware, quali opzioni sono abilitate, quali supporti vengono montati automaticamente e quali percorsi OTA accettano immagini filesystem come input.

Le vulnerabilità più gravi colpiscono mount, exFAT e nomi lunghi

Il difetto di maggiore valore offensivo indicato da runZero è CVE-2026-6682, un integer overflow nella funzione mount_volume() durante il mount di volumi FAT32. L’aritmetica interna può produrre metadati controllati dall’attaccante, poi considerati attendibili da codice downstream come lunghezze di lettura. In sistemi privi di ASLR, MPU o separazione robusta della memoria, questo passaggio può degenerare in overflow su heap o stack e aprire la strada all’esecuzione di codice. CVE-2026-6687 riguarda invece f_getlabel() su exFAT, dove una lunghezza etichetta non adeguatamente limitata può causare scritture eccessive in buffer forniti dal chiamante, spesso piccoli e allocati sullo stack negli esempi o nei wrapper generati. CVE-2026-6688 è più sottile perché dipende dai chiamanti: con Long File Name abilitato, fno.fname può raggiungere dimensioni superiori a quelle attese da molte integrazioni, che copiano il nome con funzioni come strcpy() o sprintf() dentro buffer fissi. In questi casi il bug non è soltanto nella libreria, ma nel contratto implicito tra libreria e codice applicativo. Se il firmware assume nomi brevi ma accetta supporti con nomi lunghi, il filesystem diventa un canale di corruzione memoria.

Dirty-cache, divide-by-zero e cluster non inizializzati ampliano l’impatto

Le altre vulnerabilità mostrano che la sicurezza di un filesystem embedded non riguarda solo l’esecuzione di codice. CVE-2026-6685 descrive un wrap di sottrazione senza segno nella gestione della dirty-cache su volumi frammentati, con possibilità di cache stantia, accessi fuori limite e corruzione silenziosa dei dati. Questo scenario è critico nei sistemi di logging, controllo industriale e telemetria, dove un dato corrotto può non generare crash immediati ma alterare diagnosi, audit o decisioni operative. CVE-2026-6683 riguarda un divide-by-zero nei percorsi di sync e scrittura exFAT, attivabile con metadati manipolati e capace di generare crash affidabili; nei processi di aggiornamento firmware o OTA, un crash nel momento sbagliato può diventare un vettore di brick. CVE-2026-6686 espone invece cluster non inizializzati dopo operazioni di seek oltre la fine del file, con possibile divulgazione di dati residui provenienti da file cancellati o fasi precedenti del ciclo di vita del supporto. In un wallet hardware, in un sistema di autenticazione o in un dispositivo condiviso, questo tipo di bug può trasformarsi in leak di informazioni sensibili anche senza compromissione completa del dispositivo.

Immagini FAT ed exFAT diventano input ostili

Il punto operativo della ricerca runZero è che molte vulnerabilità possono essere attivate con immagini FAT, exFAT o GPT appositamente costruite. In ambienti embedded, questi input arrivano spesso da fonti considerate normali: una SD card inserita in una telecamera, una chiavetta USB usata da un tecnico, un pacchetto OTA che contiene una partizione temporanea, un’immagine di aggiornamento per droni, un supporto di configurazione per macchine industriali o un archivio dati esportato da un altro dispositivo. La minaccia può quindi essere fisica, quando l’attaccante ha accesso breve al supporto rimovibile, oppure remota, quando la pipeline di update scarica o monta immagini controllabili. Nei sistemi embedded tradizionali la situazione è aggravata dall’assenza di difese comuni nei sistemi general purpose: niente randomizzazione degli indirizzi, isolamento limitato tra componenti, privilegi elevati nel firmware e debugging post-incidente spesso difficile. Un crash su desktop è un evento gestibile; un crash in bootloader, in OTA o in firmware industriale può rendere il dispositivo non funzionale fino a recovery fisica. Per questo i bug in FatFs hanno un blast radius superiore alla dimensione del codice.

L’AI-assisted fuzzing cambia la scoperta dei bug embedded

La ricerca nasce da un ritorno su un audit iniziato anni prima e rilanciato nel 2026 con strumenti di fuzzing assistiti da AI. runZero descrive l’uso di GitHub Copilot in modalità automatica per costruire harness, generare input e validare condizioni sfruttabili. Il dato strategico è più importante del singolo strumento: componenti maturi, piccoli e apparentemente stabili possono ancora contenere bug significativi se sottoposti a fuzzing mirato, soprattutto quando analizzano formati complessi e storicamente permissivi come FAT ed exFAT. L’automazione abbassa la barriera d’ingresso della vulnerability research e aumenta la probabilità che difetti rimasti latenti per anni vengano scoperti anche da attori meno specializzati. Per i vendor embedded questo cambia il modello di rischio: non basta considerare sicuro un componente perché è vecchio, diffuso e poco modificato. Occorre introdurre fuzzing continuo, test con immagini malformate, sanitizzatori dove disponibili, harness specifici per configurazioni abilitate e revisione delle assunzioni nei wrapper. L’adozione dell’AI nella ricerca offensiva rende queste verifiche non più opzionali.

Gli integratori devono auditare versioni vendored e wrapper

La mitigazione più urgente consiste nell’aggiornare a FatFs R0.16 o a versioni successive, ma gli sviluppatori non devono fermarsi al bump della libreria. Molti prodotti usano snapshot vendored, patch locali o fork modificati anni prima, spesso senza una tracciabilità chiara rispetto all’upstream. Serve quindi identificare la versione effettiva, confrontare le modifiche locali, verificare se exFAT, LFN, FF_LBA64 e GPT siano abilitati e analizzare i punti in cui nomi, label, dimensioni e metadati vengono copiati in buffer applicativi. I wrapper devono sostituire copie non limitate con funzioni bounded, applicare limiti espliciti su nomi ed etichette, inizializzare i cluster dopo estensioni oltre EOF, validare i conteggi GPT, gestire errori di sync senza brick e testare supporti frammentati o volutamente corrotti. Le piattaforme come ESP-IDF, STM32Cube, Zephyr RTOS, MicroPython e sistemi OTA basati su SWUpdate dovrebbero distribuire advisory chiari ai downstream, perché molti produttori finali non seguono direttamente le note di ChaN o i repository di sicurezza. In assenza di patch universali, la difesa passa da inventario, test e hardening dell’integrazione.

La sicurezza embedded passa dai componenti invisibili

Il caso FatFs dimostra che la sicurezza dei dispositivi embedded non dipende soltanto da radio, stack IP, credenziali cloud o interfacce web di amministrazione. Componenti più bassi e meno visibili, come un parser filesystem, possono diventare il primo punto di ingresso se leggono dati non fidati da supporti rimovibili o immagini di aggiornamento. R0.16 rappresenta un passo utile perché corregge almeno un problema di GPT e aggiorna il codice upstream, ma le sette vulnerabilità descritte da runZero mostrano una realtà più complessa: il rischio vive nella combinazione tra libreria, opzioni di compilazione, wrapper, pipeline OTA e assenza di protezioni memoria. Per produttori di IoT, droni, controller industriali, wallet crittografici e dispositivi con slot SD o porte USB, l’aggiornamento deve diventare parte di un ciclo di sicurezza più ampio. Ogni immagine filesystem deve essere considerata input ostile, ogni versione vendored deve essere inventariata e ogni bug “locale” deve essere valutato per il suo impatto transitorio sull’intera supply chain embedded.