CVE-2026-6682 · FatFS ≤ R0.16 FAT32 mount_volume() integer overflow (fasize *= n_fats)

01 · The Real Story

A hostile SD card that lies about its FAT geometry until the math overflows and the mount code writes wherever the attacker wants

FatFS is ChaN's tiny FAT filesystem library — the one baked into a huge fraction of the world's microcontroller firmware, from STM32 hobby projects to industrial HMIs, printers, medical infusion pumps, automotive infotainment, and consumer USB gadgets. In mount_volume() on R0.16 and earlier, the code computes fasize *= fs->n_fats where both operands come from attacker-controlled on-disk BPB fields. On 32-bit builds (the overwhelming majority of FatFS deployments) a crafted FAT32 boot sector can wrap this multiplication, producing an undersized allocation and mis-sized cluster/FAT bookkeeping. Subsequent reads/writes then index outside the intended buffers, giving memory corruption at mount time — before any file is even opened.

Vendor severity is HIGH (7.6) with vector AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The scope-changed C/I/A:H is defensible for embedded targets where a filesystem library sits in the same address space as the whole firmware — corrupting it *is* corrupting the device. But the AV:P gate is the whole story: the attacker has to physically insert media. For a fleet of servers, laptops, or cloud workloads this is essentially not a threat. For a fleet of kiosks, ATMs, PLCs, or medical devices with exposed USB/SD slots, the vendor score is honest. Reality: MEDIUM for a typical enterprise, HIGH if you own field-deployed embedded gear.

"Malicious-SD-card bug in an embedded FS library. Real risk lives in kiosks, medical devices, and OT — not your server fleet."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Craft a malicious FAT32 volume

Attacker builds a FAT32 image with BPB fields (BPB_FATSz32, BPB_NumFATs) chosen so that fasize * n_fats overflows a 32-bit unsigned. Trivially done by hand-editing sector 0 with a hex editor or a 20-line Python script; no exploit framework required. Public FAT fuzzing corpora (e.g., AFL/fatfuzz seeds) already contain overflow triggers.

Conditions required:

Ability to write a raw disk image
Knowledge of target FatFS build's word size (usually 32-bit)

Where this breaks in practice:

None — this is a text-editor step

Detection/coverage: Nothing scans removable media BPB fields for arithmetic-overflow-inducing values.

STEP 02

Deliver the media to a vulnerable device

Attacker inserts the SD card, USB stick, or eMMC-image into a device running FatFS ≤ R0.16. This is the pivotal, and limiting, step: the device must have a physically reachable removable-media port that the firmware auto-mounts. Weaponization vector is a hand-crafted FAT image (e.g., built with mkfs.fat + dd patching, or fatfuzz from strongcourage/fuzzing).

Conditions required:

Physical proximity or supply-chain interdiction of media
Firmware auto-mounts inserted volumes

Where this breaks in practice:

Servers, VMs, and cloud workloads don't use FatFS
Enterprise laptops use the OS FAT driver, not FatFS
Many embedded devices disable removable media in production
Chassis intrusion / port-blocking policy on kiosks and ATMs

Detection/coverage: USB device-control (Ivanti, CrowdStrike Device Control) blocks unknown mass-storage on enterprise endpoints, but does not apply to embedded/OT targets.

STEP 03

Trigger mount_volume() overflow

On insertion, f_mount() → mount_volume() parses the BPB and executes fasize *= fs->n_fats, wrapping to a small value. The subsequent FAT and directory reads are computed against wrong bounds, producing out-of-bounds reads/writes into adjacent heap or static buffers depending on the firmware layout.

Conditions required:

FatFS ≤ R0.16 linked in
32-bit target (or 64-bit with FF_INTDEF=1)

Where this breaks in practice:

Some vendors patch or fork FatFS internally
Some builds mount lazily and never reach this code without a user action

Detection/coverage: No CVE-specific IDS/EDR signatures; embedded devices generally have zero telemetry.

STEP 04

Achieve code execution or brick

Because FatFS runs in the same address space as the firmware (no MMU isolation on Cortex-M, and often none on Cortex-A embedded Linux firmware either), a well-placed OOB write corrupts function pointers, RTOS task structures, or return addresses — yielding arbitrary code execution at whatever privilege the firmware runs at (usually 'everything'). At minimum, the device crashes and either bricks or reboots into an unbootable state.

Conditions required:

Exploitable memory layout — heap or static region adjacent to control data

Where this breaks in practice:

MPU/MMU-protected RTOS builds limit blast radius
Secure Boot + signed firmware may prevent persistence, but not runtime code exec
Watchdog reset may frustrate reliable RCE

Detection/coverage: Field failure rate anomaly is the only realistic signal for embedded fleets.

03 · Compensating Control

Disable or physically block removable-media ports on field devices — Epoxy plugs, USB port blockers, or firmware config toggles remove the delivery vector entirely. Deploy within the noisgate MEDIUM window — no mitigation SLA applies, but for embedded/OT fleets treat as 30-day priority given safety implications.

Inventory FatFS via firmware SBOM — Use binwalk, cwe_checker, or vendor SBOMs to identify which shipped firmware images link FatFS ≤ R0.16. Query Zephyr, NuttX, ChibiOS, Azure RTOS, and vendor-forked copies specifically. Complete inventory within 30 days so remediation planning has ground truth.

Push firmware updates containing FatFS R0.16a — Coordinate with device vendors or your own firmware team to ship the upstream fix or backport the two-line overflow check. Roll out through your normal firmware-update channel within the noisgate remediation SLA of 365 days for MEDIUM, or 180 days if you re-rate to HIGH for safety-critical devices.

Enforce signed/authenticated media on high-value embedded devices — Where the device supports it, restrict mount to encrypted or signed volumes (e.g., LUKS, vendor-signed update packages). Deprives an attacker of the raw-FAT delivery path.

For CI/forensics: mount untrusted FAT images with ephemeral / sandboxed FatFS builds only — If any of your CI, malware analysis, or firmware-unpacking pipelines call FatFS on untrusted images, run them in throwaway containers or VMs and upgrade the linked FatFS immediately.

What doesn't work

EDR / antivirus on the endpoint — FatFS runs inside embedded firmware, not on your Windows/Linux hosts; endpoint security has no visibility.
Network segmentation / firewalls — the vulnerability is not network-reachable; AV:P means the packet never crosses a wire.
Filesystem scanning of the media contents — the malicious data is in the BPB (sector 0), not in files; AV file scanning won't inspect it.
Disabling FAT filesystem support in Windows/Linux — irrelevant; the vulnerable code is FatFS specifically, not the OS FAT driver.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not in CISA KEV. No public campaign reporting as of 2026-07-04.
PoC availability	No dedicated public PoC yet, but trivial to build — FatFS fuzzing harnesses in `strongcourage/fuzzing` and `google/oss-fuzz` already generate BPB-overflow inputs.
EPSS	0.0021 (~0.2 percentile) — model correctly reflects negligible mass-exploitation likelihood given `AV:P`
KEV status	Not listed. No CISA action.
CVSS 3.1 vector	`AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` — the `AV:P` is the decisive severity-limiter; scope-change is fair for embedded co-located firmware.
Affected versions	FatFS R0.16 and earlier, all configurations built with 32-bit integer defaults (default on Cortex-M).
Fixed version	FatFS R0.16a (upstream patch adds explicit overflow check on `fasize * n_fats`). Downstream: Zephyr, NuttX, ChibiOS, Azure RTOS may ship as forked copies — audit each SBOM.
Exposure telemetry	Not internet-reachable by definition (AV:P). No Shodan/Censys/GreyNoise signal is meaningful for this CVE — the exposure question is physical port count, not IP surface.
Disclosure	2026-07-01, upstream by ChaN via elm-chan.org changelog; MITRE assigned as CVE-2026-6682.
Deployment footprint	FatFS is one of the most widely embedded FAT libraries — present in millions of MCU firmware images. Enterprise servers/workstations are not affected; embedded, OT, medical, automotive, and consumer IoT are.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.4/10)

Why this verdict

Friction: physical access required — AV:P collapses the addressable population to devices with attacker-reachable removable-media ports. Servers, VMs, laptops (which use OS FAT drivers, not FatFS) are unaffected.
Friction: FatFS is not on IT endpoints — the library ships inside firmware, not on Windows/Linux/macOS user devices. If you're not shipping firmware or operating embedded gear, your exposed count is zero.
Friction: EPSS 0.002 and no KEV — signals from both worldwide-observed-exploitation datasets align with the AV:P reality: this will not become a mass-exploitation event.
Role multiplier: workstation/server fleet — chain does not succeed; FatFS is not present. Blast radius: none.
Role multiplier: kiosks, ATMs, printers, MFPs, digital signage — chain succeeds if USB/SD is reachable; blast radius: single device compromise, possibly network pivot if device is dual-homed. Verdict floor for this role: MEDIUM.
Role multiplier: medical devices, industrial PLCs/HMIs, automotive ECUs — chain succeeds; blast radius includes safety-of-life or OT process impact. For organizations with such devices, this is HIGH and the verdict floor rises accordingly.
Role multiplier: build systems that mount untrusted FAT images (forensics workstations, CI that unpacks firmware) — chain succeeds via a mounted image file, not physical media; blast radius: build-server compromise. Rare but worth SBOM-checking.

Why not higher?

Not HIGH for a general enterprise because the affected component is not present on the IT fleet and the attack requires physical media insertion, which excludes remote adversaries entirely. If your organization operates field-deployed embedded devices, medical equipment, or ICS/OT with FatFS in the firmware, you should locally re-rate this as HIGH per the role-multiplier analysis above.

Why not lower?

Not LOW because the vulnerability is a real memory-corruption bug in mount-time parsing, exploitable pre-authentication once media is inserted, and FatFS is genuinely ubiquitous in embedded firmware. Anyone running kiosks with exposed USB, digital signage, medical devices, or PLCs has a plausible physical-attack path with device-compromise blast radius.

06 · Verification

Crowdsourced verification payload.

Run this on any Linux host, forensics workstation, or CI runner that stores firmware images. Invoke as ./check-fatfs.sh /path/to/firmware_dir — no root required, just read access to the firmware artifacts. It greps unpacked firmware trees for FatFS version strings and known-vulnerable ranges.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-fatfs.sh — detect FatFS <= R0.16 in unpacked firmware trees
# Usage: ./check-fatfs.sh <path-to-firmware-tree>
# Exits: 0 = PATCHED / not present, 1 = VULNERABLE, 2 = UNKNOWN
set -u

TARGET="${1:-.}"
if [ ! -d "$TARGET" ]; then
  echo "UNKNOWN: $TARGET is not a directory"
  exit 2
 fi

FOUND_ANY=0
FOUND_VULN=0

# Search source drops (ff.c, ff.h) and stripped binaries
while IFS= read -r -d '' f; do
  FOUND_ANY=1
  # elm-chan revision string, format like "R0.15", "R0.16", "R0.16a"
  ver=$(strings "$f" 2>/dev/null | grep -Eo 'R0\.[0-9]+[a-z]?' | head -n1)
  if [ -z "$ver" ]; then
    continue
  fi
  echo "[i] $f -> FatFS $ver"
  # Vulnerable: everything <= R0.16 without an 'a' or later suffix
  case "$ver" in
    R0.16a|R0.16b|R0.16c|R0.17*|R0.18*|R0.19*)
      ;;
    R0.16)
      FOUND_VULN=1
      echo "[!] VULNERABLE: $f contains FatFS R0.16 (no fix suffix)"
      ;;
    R0.1|R0.2|R0.3|R0.4|R0.5|R0.6|R0.7|R0.8|R0.9|R0.10*|R0.11*|R0.12*|R0.13*|R0.14*|R0.15*)
      FOUND_VULN=1
      echo "[!] VULNERABLE: $f contains FatFS $ver (< R0.16a)"
      ;;
  esac
done < <(find "$TARGET" -type f \( -name 'ff.c' -o -name 'ff.h' -o -name '*.bin' -o -name '*.elf' -o -name '*.hex' -o -name '*.img' \) -print0)

if [ "$FOUND_ANY" -eq 0 ]; then
  echo "PATCHED: no FatFS artifacts found under $TARGET"
  exit 0
fi
if [ "$FOUND_VULN" -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
fi
echo "PATCHED"
exit 0