In FatFS R0

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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.

#!/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

Sources

1. FatFS official site (ChaN, elm-chan)
2. FatFS updates / revision history
3. NVD CVE-2026-6682
4. MITRE CVE-2026-6682
5. CWE-190: Integer Overflow or Wraparound
6. FIRST EPSS lookup
7. CISA Known Exploited Vulnerabilities Catalog
8. Zephyr FatFS module (common downstream consumer)