CVE-2026-6684: Elm-chan FatFs DOS Vulnerability

CVE-2026-6684 Overview

CVE-2026-6684 affects FatFs versions prior to R0.16 when compiled with FF_LBA64 = 1 to enable GUID Partition Table (GPT) scanning. The library derives an unbounded loop count from the GPTH_PtNum field in the GPT header, allowing extremely long or effectively infinite mount-time scans. An attacker with physical access to a storage device can craft a malicious GPT header that stalls the mounting process, resulting in denial of service on embedded systems that rely on FatFs. The flaw is classified under CWE-835 (Loop with Unreachable Exit Condition).

Critical Impact
A crafted GPT header can trigger a non-terminating scan loop during volume mount, halting availability of any FatFs-backed storage subsystem on affected embedded devices.

Affected Products

Elm-chan FatFs versions prior to R0.16
Embedded firmware and IoT devices bundling FatFs with FF_LBA64 = 1
Storage subsystems using FatFs GPT scanning code paths

Discovery Timeline

2026-07-01 - CVE-2026-6684 published to NVD with advisory from runZero
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-6684

Vulnerability Analysis

FatFs is a generic FAT/exFAT filesystem module written by ChaN, widely embedded in microcontroller firmware, real-time operating systems, and IoT devices. When the build option FF_LBA64 is set to 1, FatFs enables GPT parsing to support disks larger than 2 TiB. During volume mount, the library reads the GPT header and iterates over partition entries using the GPTH_PtNum field as the loop bound.

The vulnerability stems from FatFs trusting the attacker-controlled GPTH_PtNum value without validating it against a sensible upper limit. A maliciously formed GPT header can specify an enormous partition count, causing the scanning loop to run for a prohibitively long time. On resource-constrained embedded targets, this manifests as a hung mount operation and effective denial of service.

Root Cause

The root cause is a missing bounds check on a length field parsed from untrusted input. FatFs uses GPTH_PtNum directly as an iteration count in the GPT partition entry scan without capping it against the GPT specification maximum or the size of the available partition entry array. This maps to CWE-835, where the exit condition of the loop is controlled entirely by external data.

Attack Vector

Exploitation requires local, physical access to insert or attach a storage device with a crafted GPT header. When the target system attempts to mount the volume, the FatFs library enters the extended scan loop and consumes CPU cycles indefinitely. No authentication or user interaction beyond media insertion is required. The impact is limited to availability, with no confidentiality or integrity effect. For technical specifics, see the runZero security advisory and the runZero blog on FatFs bugs.

Detection Methods for CVE-2026-6684

Indicators of Compromise

Embedded devices or IoT endpoints becoming unresponsive shortly after insertion of external storage media
FatFs-based firmware exhibiting sustained CPU utilization on a single mount thread with no I/O progress
Repeated watchdog resets triggered during volume mount operations on devices supporting GPT disks

Detection Strategies

Inventory firmware and embedded products to identify components that link FatFs and enable FF_LBA64 = 1
Fuzz GPT header parsing during firmware validation using crafted GPTH_PtNum values to confirm the presence of the loop bound check
Correlate device availability telemetry with removable media insertion events to surface abuse patterns

Monitoring Recommendations

Log USB and storage attach events on managed embedded hosts and alert on devices that immediately stall mount operations
Track firmware versions across the fleet and flag those shipping FatFs versions earlier than R0.16
Monitor operational availability metrics for kiosks, industrial controllers, and medical devices that accept external storage

How to Mitigate CVE-2026-6684

Immediate Actions Required

Upgrade FatFs to release R0.16 or later in all affected firmware builds
Restrict physical access to devices that mount user-supplied storage media
Where feasible, disable GPT support by building FatFs with FF_LBA64 = 0 if 64-bit LBA is not required

Patch Information

The issue is resolved in FatFs R0.16, which introduces bounds enforcement on the partition entry count parsed from the GPT header. Downstream vendors that redistribute FatFs in firmware must rebuild and reissue their images. Refer to the Elm-chan FatFs project page for release artifacts and the runZero vulnerability repository for reproducer details.

Workarounds

Reject external storage insertion at the application layer until firmware is updated
Apply a local patch that clamps GPTH_PtNum to the GPT specification maximum of 128 entries before entering the scan loop
Wrap the mount call with a hardware watchdog or timeout to terminate scans exceeding an acceptable duration

bash

# Configuration example: disable 64-bit LBA / GPT parsing in ffconf.h if not required
#define FF_LBA64 0