mirror of
https://github.com/espressif/esp-idf.git
synced 2026-09-22 13:01:16 +03:00
fc33b0dcde
The initial CVE-2026-6682 fix hardened the exFAT mount path, but the CVE as reported by runZero is a FAT32 defect in mount_volume() and is reachable in the default configuration (exFAT and 64-bit LBA disabled). This corrects the fix. Root cause: `fasize *= fs->n_fats` is a DWORD multiply with no overflow guard. A crafted BPB_FATSz32 such as 0x80000001 with NumFATs=2 wraps `fasize` to 0x00000002. The wrapped (too-small) FAT size places `fs->database` inside the FAT region, so a forged directory entry yields an attacker-controlled `finfo.fsize`; a caller using it as a read length overflows its buffer with attacker-controlled bytes (CVSS 7.6). Fix: reject per-FAT and reserved+FAT+root system-area sizes that overflow DWORD before they are used to derive the data-area base. The exFAT cluster-heap/bitmap 64-bit promotions are retained as defense-in-depth and relabeled (they are not CVE-2026-6682). SBOM reason updated.
21 lines
2.2 KiB
YAML
21 lines
2.2 KiB
YAML
name: 'FatFs'
|
|
version: 'R0.15'
|
|
supplier: 'Organization: Espressif Systems (Shanghai) CO LTD'
|
|
originator: 'Person: ChaN'
|
|
description: 'Generic FAT Filesystem Module for embedded systems.'
|
|
cve-exclude-list:
|
|
- cve: CVE-2026-6682
|
|
reason: FAT32 integer overflow in mount_volume(). Patched by rejecting per-FAT and system-area sizes that overflow the 32-bit multiply before use; the exFAT cluster-heap/bitmap multiplies were additionally widened to 64-bit as defense-in-depth.
|
|
- cve: CVE-2026-6683
|
|
reason: exFAT divide-by-zero when NumClusters == 0. The vulnerable exFAT PercInUse sync division was introduced in R0.16 and is not present in this R0.15 release; an empty cluster heap is additionally rejected at mount as defense-in-depth.
|
|
- cve: CVE-2026-6685
|
|
reason: Unsigned-subtraction wrap in the dirty-cache refill check. Patched by requiring the cached sector to lie within the direct-I/O range in both f_write() and f_read().
|
|
- cve: CVE-2026-6687
|
|
reason: exFAT label-length overflow in f_getlabel(). Patched by clamping XDIR_NumLabel to the 11-unit exFAT label maximum.
|
|
- cve: CVE-2026-6684
|
|
reason: GPT partition-scan loop DoS, classified by runZero as pre-R0.16 because the protective GPT validation was added upstream in R0.16. This release does not ship the R0.16 baseline; it ships FatFs R0.15 with Espressif patch2, which already backports that validation. test_gpt_header() checks the GPT header size, CRC and entry size and rejects any partition table declaring more than 128 entries before the scan loop runs, so the unbounded-scan condition is unreachable. An unpatched upstream R0.15 (without patch2) would remain vulnerable.
|
|
- cve: CVE-2026-6686
|
|
reason: Read of uninitialized clusters after f_lseek() extends a file past EOF. Longstanding FatFs behavior; not a memory-safety defect and zero-filling every extended cluster is prohibitively costly on flash. Applications sharing media across trust boundaries must zero regions before exposing them.
|
|
- cve: CVE-2026-6688
|
|
reason: Long-filename overflow in downstream callers copying FILINFO.fname. Not exposed in ESP-IDF; vfs_fat.c uses bounded snprintf/strlcpy and fname is bounded in-library by FF_MAX_LFN.
|