FatFS exFAT label-length stack overflow in f_getlabel()

Executive summary #

CVE-2026-6687 affects ChaN's FatFs R0.16 and earlier. The bug is a stack overflow in f_getlabel() because exFAT label length (XDIR_NumLabel) is trusted without enforcing spec maximums. This maps to CWE-121 (Stack-based Buffer Overflow). Estimated CVSS v3.1 vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (7.6, High). The estimated CISA SSVC vectors are Exploitation: PoC, Technical Impact: Total.

Identified downstream projects include STMicroelectronics Middleware FatFS MCU, Zephyr Project Zephyr RTOS, ArduPilot, RIOT OS, and Damien P. George's MicroPython derivatives that call f_getlabel() on attacker-controlled exFAT media.

Technical details #

The vulnerable loop copies label characters using on-disk count directly:

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

exFAT expects volume label lengths up to 11, but XDIR_NumLabel is a byte and can be set much larger (for example, 128 or 255). Typical calling code uses fixed stack buffers such as char label[12] or char label[24], resulting in substantial overwrite beyond buffer bounds.

Example caller pattern:

char label[12];
DWORD vsn;
f_getlabel("0:", label, &vsn);  <i>/* overflow on crafted exFAT */</i>

For more details, see https://github.com/runZeroInc/vulns-2026-fatfs-chance

Attacker value #

An attacker can convert media insertion and routine label queries into a memory-corruption primitive with strong code-execution potential on bare-metal targets lacking modern mitigations.

Downstream reach is significant through STMicroelectronics Middleware FatFS MCU-generated projects and RTOS ecosystems that expose storage metadata during boot or diagnostics.

Credit #

Discovered by HD Moore, CVE coordination by Tod Beardsley, both of runZero, Inc.

Timeline #

• 2026-03-17 (Tue): Initial findings discovered and documented
• 2026-04-20 (Mon): CVE IDs reserved
• 2026-04-20 (Mon): Initial outreach to the provider, ChaN (no response)
• 2026-04-27 (Mon): Outreach to JPCERT/CC for coordination help (TN: JPCERT#96 280429)
• 2026-04-28 (Tue): JPCERT/CC outreach to the provider in Japanese (no response after three attempts)
• 2026-05-14 (Wed): Outreach to a major downstream implementor upon JPCERT/CC recommendation (responded, but unwilling to receive full details)
• 2026-06-18 (Thu): Updated JPCERT/CC and downstream vendor with a date change to Jul 1 for disclosure
• 2026-07-01 (Wed): Public disclosure of CVE-2026-6682