CVE-2026-6684: FatFs GPT Parser Denial of Service Vulnerability (CWE-835)

Technical summary

The vulnerability resides in FatFs's GPT partition table parser when FF_LBA64 = 1 is configured. The code reads the GPTH_PtNum field from the GPT header to determine how many partition entries to scan, but does not properly bound or validate this count. An adversary can set GPTH_PtNum to an extremely high value (e.g., 0xFFFFFFFF or similar), causing the parsing loop to iterate an unbounded number of times. This maps to CWE-835 (Loop with Unreachable Exit Condition), where the loop's termination condition is either unreachable or dependent on untrusted external data. The loop executes during filesystem mount, making the device unresponsive until power-cycled or the operation times out (if timeout handling exists). No memory corruption or data compromise occurs; impact is purely availability-based.

Business impact

Embedded systems and IoT devices relying on FatFs for SD card, USB storage, or other removable media access become vulnerable to denial of service when an attacker gains physical access to supply a malicious storage device. In industrial, medical, or critical infrastructure deployments, this could prevent a device from booting or resuming operation, disrupting business continuity. For consumer devices, the attack surface is limited by physical access requirements, but in shared environments (kiosks, public terminals, medical devices in hospitals) the risk is elevated. The impact is operational downtime rather than data breach or system compromise.

Affected systems

FatFs versions prior to R0.16 that are compiled with GPT support (FF_USE_LBA64 or equivalent) and 64-bit LBA enabled (FF_LBA64 = 1). This affects embedded systems, microcontroller projects, automotive infotainment systems, industrial equipment, medical devices, and any IoT platform using FatFs for removable media support. Systems using only MBR (Master Boot Record) partitioning or with GPT support disabled are not affected. Verify your FatFs version and configuration flags in your project's ffconf.h or equivalent build configuration.

Exploitability

Exploitation requires physical access to craft a malicious storage device (SD card, USB drive, external SSD) with a modified GPT header. The attack is trivial from a technical perspective—writing a specific byte value to the GPT header—and requires no authentication or user interaction once the device is inserted. However, the attack surface is constrained by the physical access requirement. CISA's estimated SSVC vectors indicate Exploitation level is PoC (proof-of-concept available), meaning reliable attack demonstrations exist but weaponized exploits may not yet be broadly distributed. Organizations in environments with loose physical security or shared device access face higher practical risk.

Remediation

Upgrade FatFs to version R0.16 or later, which includes validation and bounding of the GPTH_PtNum field to prevent unbounded loop execution. During the upgrade, verify that your build configuration properly enables the GPT parsing module and test with both well-formed and intentionally malformed partition tables to confirm the fix. For legacy systems that cannot be upgraded immediately, consider disabling GPT support if MBR partitioning is sufficient, setting FF_USE_LBA64 = 0 in the configuration. Implement physical access controls to prevent unauthorized insertion of untrusted storage devices.

Patch guidance

Obtain FatFs R0.16 or later from the official elm-chan FatFs repository (http://elm-chan.org/fsw/ff/00index_e.html). Review the release notes and changelog for the specific fix to GPTH_PtNum validation. In your embedded project, update the FatFs source files, recompile with your existing ffconf.h settings, and perform regression testing on your target hardware with both standard and edge-case partition table layouts. If your project uses a fork or vendor-modified version of FatFs, contact your vendor for an updated release or backport the fix manually (the change should be isolated to the GPT parsing logic). Test on representative storage devices used in your deployment.

Detection guidance

Monitor for mount failures or unexplained system hangs when inserting external storage devices. If your system includes logging, check for timeout messages during the filesystem initialization phase. For development and testing, simulate the attack by using a disk editor or specialized tool to modify the GPTH_PtNum field in a test storage device's GPT header and confirm that your patched version handles it gracefully (either rejecting the partition table or completing the scan in reasonable time). In production, implement a watchdog timer or mount operation timeout to prevent indefinite hangs; if a mount attempt exceeds a threshold (e.g., 30 seconds), log an alert and forcibly abort the operation.

Why prioritize this

Although the CVSS score is 4.6 (Medium), the vulnerability should be prioritized for remediation because it affects a foundational component used across many embedded and IoT ecosystems. The simplicity of exploitation and the requirement for only physical access make it a practical concern in high-physical-security environments or shared-access scenarios. For systems in customer premises, vehicles, or untrusted locations, the attack surface is non-negligible. However, organizations with strict physical security policies or those not using GPT partitioning can safely defer patching; the medium CVSS and lack of KEV status indicate this is not an emergency across all deployments.

Risk score, explained

The CVSS v3.1 score of 4.6 (Medium) reflects the high severity of denial of service (Attack Vector: Physical, Availability Impact: High) tempered by the requirement for physical access and the absence of confidentiality or integrity impact. The vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H confirms that once an attacker has physical access, the attack is trivial (low complexity, no privileges or user interaction required) and guaranteed to cause a significant availability disruption. CISA's SSVC assessment (Exploitation: PoC, Technical Impact: Partial) aligns with this: the vulnerability is demonstrable but not yet mass-exploited, and the harm is confined to availability rather than widespread system compromise. Organizations should weigh this score against their physical security posture and the criticality of devices in their environment.

Frequently asked questions